On Tue, Jul 05, 2022 at 09:32:59AM +0200, Ralf Hemmecke wrote:
>
> >>If you do not accept that position, then another simple idea is that
> >>for the variable name is only really a problem, if we have SUP(A) and SUP(B)
> >>with different coefficient rings A and B. That, however, leads to two
> >>instantiations of SUP, right? What about simply generating a new lisp symbol
> >>with every instance of SUP and store it as a domain variable/constant. That
> >>symbol would then be used for output. No need to change OutputForm.
> >
> >That has many problems. One is getting unpredictable variable names.
>
> Hmmm... what variable name would (SCOPE "?") give?
>
> >Another is that logically the same domain may be re-instantiated
> >effectlevely getting different name.
>
> Yes. But why would that be a problem? For debugging purposes, it's
> completely enough if one can figure out to what the printed "?" belongs to
> and that would be easy if it prints as "%s3" or so.
>
> >Change to OutputForm is appropriate as only output is affected:
> >if nobody looks at output then new OutputForm will be unused...
>
> You say it. If no output is produced, then everything is irrelevant.
> But why constructing a new output form? Let's take SUP(R). In order to be
> able for this domain to produce "(SCOPE "?") as an output form, it would
> have to investigate the structure of R. Now let's suppose that can be done.
> Then a formatter get's (SCOPE "?") and has to translate it into something
> that looks like a variable, "?'" or "?1". However, SUP instead of giving
> (SCOPE "?") could immediately use "?'" or "?1" as variable name.
>
> The same can apply for Union(X, "failed"), although Union is a somewhat
> special case.
>
> I am not convinced that introducing a new marker in OutputForm is really
> needed.
>
> I also wonder how a domain/package can actually recognize that it would have
> to output its variable as (SCOPE "?") instead of simply "?".
I think it is better to explain more how SCOPE is supposed to
work and what problem it solves. Main point is that coerce
to OutputForm works in recursive way, so at any point coerce
need to work with incomplete information. To avoid variable
clashes we need semi-global approach, that is coordinate
use of varibables on for whole expression or sequence of
expressions.
With SCOPE coerce can work alost as it works now: affected
domains will always wrap output in SCOPE marker, so no
need to "recognize". Also, the whole output of coerce
will be wrapped, so change to coerce will be quite small.
Actual renaming of variables will be done as optional
and configrable extra transformation of output form.
AFAICS simple modification to 'precondition' should
handle this for formatters that call 'precondition'
(hopefull all our formatters). So the most impact
will be on external users. That is why I sent my
initial message: it is intended as early warning
to any such users.
More generally, the idea is that we can have more
flexible relation between output form and actual
output. That is we can do various transformation
on output form. For example, with SCOPE markers
appropriate transformer could reorder terms of polynomial
so that computations would user order optimal
from computational point of view and output
could be in user-preferred order (currently
output form mostly follows internal structure,
so people are forced to use different types to
change form of output).
Note: such transformations are possible now and some
are done by default. But they may be wrong for
some domains, so we need extra semantic info in
output form to make sure such transformations
are reliable.
You somewhat think that changing output form
is problematic. Well, output form is internal
to FriCAS so from point of view of compatibility
change to output form is preferable compared
to changes to visible interfaces. And IMO to
improve output we need to change structure of
output form. Introducing SCOPE markers is
just one step in this direction.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20220707013909.GA12604%40fricas.math.uni.wroc.pl.
