Ralf Hemmecke wrote:
>
> No time yet to look in deeper detail to Waldek's proposal...
>
> > a choice of a fixed variable seems unnatural to me and may interfere
> > with other calculations, it is simple enough to do
> > p::UP(x, R)
> > or the like.
>
> There is also a function "outputForm".
>
> And... maybe, we change the default unknown-variable-name from "?" to
> "#". The question mark always looks a bit as if there were an error and
> the system didn't know how to handle it. I don't even think that it
> would hurt if we show the default variable of SparseUnivariatePolynomial
> as "x".
I see no reason to prefer '#' over '?'. In both cases user has
to know the convention, which is fine if SparseUnivariatePolynomial
shows only in advanced uses. Concerning 'x': currently there
is no confusion over variables if we print
SparseUnivariatePolynomial(Polynomial(...)) and Polynomial uses
normal variables. Using normal variables will add mew case
when output is ambigous.
> Maybe the bigger problem is if there is a non-trivial element of
> SUP(SUP(INT)) shown.
Yes, this is a problem. And this IMHO means that we should
limit use of SparseUnivariatePolynomial in user interface.
--
Waldek Hebisch
[email protected]
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
