On Jun 26, 2008, at 10:56 PM, Carl Witty wrote: > Consider the following Sage run, from Sage 3.0.3: > > sage: x1 = PolynomialRing(ZZ, 'x').gen() > sage: x2 = PolynomialRing(ZZ, 'x', sparse=True).gen() > sage: (x1+x2).parent() > Univariate Polynomial Ring in x over Integer Ring > sage: (x2+x1).parent() > Univariate Polynomial Ring in x over Integer Ring > > where we see that the sum of a sparse and a dense polynomial is > dense. Then consider this run, which is the same except for > exchanging the last two lines: > > sage: x1 = PolynomialRing(ZZ, 'x').gen() > sage: x2 = PolynomialRing(ZZ, 'x', sparse=True).gen() > sage: (x2+x1).parent() > Sparse Univariate Polynomial Ring in x over Integer Ring > sage: (x1+x2).parent() > Sparse Univariate Polynomial Ring in x over Integer Ring > > where we see that the sum of a sparse and a dense polynomial is > sparse. > > This is because: > > sage: x1.parent() == x2.parent() > True > > and the coercion code believes that if the parents are equal, it > doesn't matter which one it picks. > > First: do people think it's a problem that the results in one Sage run > are different from results in another run, depending on which command > you happen to type first?
Yes, I do. (In this particular case, I'm not sure that having x1+x2 live in a different parent than x2+x1 is a good idea either, for consistency and efficiency reasons.) > If it is a problem, the only way I can think of to fix it is to > separate the concepts of mathematical equality and implementation > equality for parents, so that users can use mathematical equality if > they want, but coercion only looks at implementation equality. Can > anybody think of a better way to fix the issue? This sounds like a good approach. Then it would look for a coercion that goes exactly one direction. This is not just an issue of equality, it will happen whenever there is a cycle in the coercion diagram. > If we fix the issue by splitting mathematical equality from > implementation equality, which concept should get "==", and what name > should the other concept get? What exactly is meant by "mathematical equality" is a potentially vague notion. There is the notion of isomorphic (which depends on the category), canonically isomorphic, equivalent (e.g. Z[x] and Z[y] are isomorphic, but I don't want Z[x] == Z[y]), and identical (distinguishing sparse vs. dense). As for a name for this last one, "same_as" or something like that? It would default to == unless overridden. From an aesthetic point of view I would like == distinguish between variable names/orderings/choice of basis/etc. but not between sparse/dense. This potentially causes issues though, for example in dictionaries/lists that use cmp internally: sage: R = PolynomialRing(ZZ, 'x', sparse=True) sage: S = PolynomialRing(ZZ, 'x', sparse=False) sage: L = [R, S] sage: L.index(S) 0 (Dicts and sets seem to work as they have different hash values (violating the python equality contract).) Thank you for bringing this up. I think we need to have clear semantics on what == means. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
