Coercion issue between sparse and dense polynomial rings
Carl Witty
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?
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?
If we fix the issue by splitting mathematical equality from
implementation equality, which concept should get "==", and what name
should the other concept get?
By the way, this behaves exactly the same in the current coercion
branch.
Carl
Robert Bradshaw
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