Hey,
Things like this have popped up in a few places, where doing things in a
fraction field over ZZ behaves much better than over QQ. I feel that
anytime we're constructing a fraction field from a ring R over a fraction
field F, we should make R over the ring used to construct F so reductions
(mainly gcd) are better behaved. For example, suppose we are constructing
QQ(q) from R = QQ[q] (so F = QQ), we would do so by changing R to be over
ZZ and then construct the fraction field (where the result would be over
QQ). I feel like this something that we could do behind the scenes, but
would solve (or at least greatly help) problems like this one.
Best,
Travis
On Thursday, September 18, 2014 7:09:03 AM UTC-7, Clemens Heuberger wrote:
>
> Up to now, my understanding was that if a == b, then hash(a) must be
> hash(b).
>
> However, this does not necessarily hold in the Fraction Field of
> Univariate
> Polynomial Ring in t over Rational Field, as the following example shows:
>
> sage: R.<q> = QQ[]
> sage: a = 1/q
> sage: b = 2/(2*q)
> sage: hash(a) == hash(b)
> False
> sage: a == b
> True
> sage: set([a, b])
> set([1/q, 2/(2*q)])
>
> This does not occur over the integers:
>
> sage: R.<z> = ZZ[]
> sage: c = 1/z
> sage: d = 2/(2*z)
> sage: hash(c) == hash(d)
> True
> sage: c == d
> True
> sage: set([c, d])
> set([1/z])
>
> This does also not occur in the symbolic ring:
>
> sage: var('s')
> s
> sage: e = 1/s
> sage: f = 2/(2*s)
> sage: hash(e) == hash(f)
> True
> sage: e == f
> (1/s) == (1/s)
> sage: bool(e == f)
> True
> sage: set([e, f])
> set([1/s])
>
> Is this behaviour intentional or is this a bug?
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" 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/sage-devel.
For more options, visit https://groups.google.com/d/optout.
