Ralf Hemmecke wrote:
>
> Anyway, it's well known that I don't like Expression(X).
> Yes, I see its usefulness in some cases, in particular when it
> represents a tower of field extensions as a rational function over
> kernels. But, it's hard to explain to a user, what the X in the argument
> actually is and for why it is useful to have such a parameter.
>
> For someone who uses FriCAS, it would probably be better to simply see
> Expression (no arguments). A domain with argument might be useful
> internally (for library writers), but in general I don't see usefulness
> for the ordinary user.
>
> For library developers, however, I think, Expression(R) is overloaded.
> Looking at its implementation reveals that it doesn't have just one
> representation. There is
>
> Fraction(MP) if R has IntegralDomain
> MP if R has Ring (but not IntegralDomain)
> FreeAbelianGroup K if R has AbelianMonoid
> K otherwise
>
> K ==> Kernel %
> MP ==> SparseMultivariatePolynomial(R, K)
>
> So, Expression(R) is, in fact, four domains put under one roof. I
> haven't looked much into the details, but just from that Rep stuff, it
> would probably make sense to untangle these different use cases
> (representations) into different domains with clear specification (and
> perhaps documented use cases) and then write Expression(R) simply as a
> wrapper domain for them (if that is still interesting).
Actally, there is common idea behind all Expression domains. Namely
genaral case is expression trees: expression is either operator
applied to arguments (which again are expressions), variable or
a constant. X in Expression(X) provides constants. In ideal
word equality in Expression(X) would consider theory of X, that
is e1 = e2 would means that there is provable that for all
possible values of variables there is equality. Of course
such equality is undecidable in general and we have no
computational representation of axioms of X. But we may try
to give conservative approximation, namely equality in
Expression(X) implies mathematical equality (defined via
provability). Without any knowledge about X all we can
do is equality of expression trees. We get better
approvimation to mathematical equality if we take some
properties of X into account. When X is IntegralDomain
equality in Expression is very good approximation to mathematical
equality. In other case not so. Of course, implementaion
is irregular and this irregularity is visible to users.
In the past I was thinking about splitting Expression into
more domains. But IMO if we do so it will be due to
pragmatic reasons. Conceptually Expression is OK.
--
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.
