#14711: Weak references in the coercion graph
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-6.0
Component: number fields | Resolution:
Keywords: memleak, number | Merged in:
field, QuadraticField | Reviewers:
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | ee30c20b0adc9878a13c8286c96ee5e972e2b002
u/SimonKing/ticket/14711 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:155 SimonKing]:
> Isn't this what happens when doing `==` in python?
No it doesn't:
{{{
sage: class T(object):
....: def __eq__(self,other):
....: return False
....:
sage: a=T()
sage: a == a
False
}}}
and in fact, there is a famous object in standard Python with this
property:
{{{
sage: float(NaN)
nan
sage: nan=float(NaN)
sage: nan == nan
False
}}}
There is a documented optimization in dictionaries: Upon key lookup,
identity is tested before equality is tried. This has odd consequences
when `NaN` is used as a key in a dict: If you use the identical `NaN`,
lookup will succeed, but not with any other `NaN`.
> Indeed. But I think we already have a ticket for comparison of ideals---
with the additional complication that the hash of ideals must involve a
Gröbner basis computation as well.
Hm, that's not clear to me. In order to have a GOOD hash it seems
something like a groebner basis needs to be involved. but for some
applications using the same hash as the ring would also be a great hash.
Of course, in many cases a groebner basis is going to be required anyway
(are ideals with different monomial orders automatically non-equal?), so
perhaps basing the hash on it isn't such a big deal.
It is an indication that ideals shouldn't be used as keys in dictionaries,
where their hash would be required. In particular, it means schemes
shouldn't be produced from an ideal (literally) but from a list of
generators. Otherwise we're going to be in trouble if schemes ever were to
become UniqueRepresentation.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:156>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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-trac.
For more options, visit https://groups.google.com/groups/opt_out.
