On 26 March 2015 at 03:31, Ralf Hemmecke <[email protected]> wrote: > On 03/26/2015 04:25 AM, Waldek Hebisch wrote: >> It makes sense to remove implementation of 'map' from >> 'ExpressionFunctions2' in non-Ring case, > > Yes. Removal of bug is always good. > > 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.
It is both natural and common to consider polynomials over some specified coefficient ring. Why should this be "hard to explain" when thinking of more general expressions as an extension of such polynomials? > > 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. ??? What would Polynomial mean if we did not have to specify say, Polynomial Integer? > > 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) > The most central idea that unites all of these representation is the notion of Kernel. K ==> Kernel % MP ==> SparseMultivariatePolynomial(R, K) After a lot of reflection the idea to build the domain of expressions on top of rational functions, i.e. Fraction(MP), seems quite brilliant to me. > 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). > I would be strongly against this. > In fact, even though I came up with Expression List Integer, I fail to > see where it would be useful. > Presumably it might be interesting to consider symbolic extensions of such lists - why not? Bill. -- 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.
