On Wed, Sep 7, 2011 at 1:07 PM, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Volker, hi William,
>
> On 7 Sep., 19:42, Volker Braun <vbraun.n...@gmail.com> wrote:
>> For ideals in Sage, comparison (==) means mathematical equality.
>
> Only in an ideal world. In fact, == is not transitive in Sage: GF(2)
> (1)==1==GF(3)(1), but GF(2)(1)!=GF(3)(1).
I know you were making a pun, but just for clarification, what Volker
said is exactly right. E.g.,
sage: R.<x,y> = QQ[]
sage: I = R.ideal([x^2, 3*y^2, x^2 - y^2])
sage: J = R.ideal([x^2, y^2, y^2 - x^2])
sage: I
Ideal (x^2, 3*y^2, x^2 - y^2) of Multivariate Polynomial Ring in x, y
over Rational Field
sage: J
Ideal (x^2, y^2, -x^2 + y^2) of Multivariate Polynomial Ring in x, y
over Rational Field
sage: I == J
True
sage: I.__cmp__??
...
l = self.groebner_basis()
r = other.groebner_basis()
...
return cmp(l,r)
>
>> I think it would be more consistent to demand mathematical equality for
>> equality of the quotient rings. It is very likely that this is what the user
>> actually wants if he/she compares two quotient rings.
>
> Unfortunately, equality tests happen implicitly when using coercion:
> There is a cache indexed by parents. Thus, if you have a quotient ring
> Q=R/I and want to add an element of Q with an element of R, then
> equality is tested for Q, in order to see whether there is an
> appropriate coercion in the test.
>
> Hence, equality test ought to be as fast as possible. Ideally, parents
> are equal if and only if they are identical.
>
> Moreover, ideals must not be used as a key of a dictionary:
> sage: P.<x,y> = QQ[]
> sage: I = P*[x,y]
> sage: hash(I)
> 6308421454588240813
> sage: J = P*[x+y,-y]
> sage: hash(J)
> 5043924375983940909
> sage: I==J
> True
>
> In other words, I and J are equal, but have different hash. Actually,
> I think it is a bug that hash(I) does not result in a TypeError.
It's a bug that hash isn't canonical. One should compute a standard
form for I before hashing it. At least this is what happens with
ideals of rings of integers of number fields. (I'm not claiming that
hash is good -- it's something dumb like hashing the Pari HNF string,
but still it is well defined.)
> That's why I think one should simplify the equality test to rely on
> the generator list of the ideals, not on equality of the ideals as
> sets.
I've changed my perspective to disagree with this.
I good compromise may be the following. When creating a quotient
ring, compute a standard form for the ideal. Then when testing
equality of two quotient rings, the whole issue we're talking about
vanishes. If you're going to do any nontrivial arithmetic in the
quotient ring, you'll *need* this standard form anyways. So just
compute it up front. In a multivariate poly ring it would be computed
via something like his:
self.change_ring(R.change_ring(order="degrevlex")).groebner_basis()
(code copied from the __cmp__ method.) The point is that degrevlex
GB's are faster to compute than wrt other term orders... and for our
purposes a GB wrt any term order suffices.
William
>
> Best regards,
> Simon
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
