#10448: Extensions of ZZ are not unique parents
-----------------------------------------+----------------------------------
Reporter: SimonKing | Owner: davidloeffler
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.6.2
Component: number fields | Keywords: uniqueness of parents
Author: Simon King | Upstream: N/A
Reviewer: | Merged:
Work_issues: Breaks garbage collection |
-----------------------------------------+----------------------------------
Changes (by davidloeffler):
* status: needs_review => needs_work
* work_issues: => Breaks garbage collection
Comment:
There is a risk of this breaking garbage collection of number fields.
The number field code is quite carefully written so that number fields are
globally unique, but only weak references to them are cached, so the
uniqueness doesn't mean they hang around in memory longer than they
should. The patch here would have the disadvantage that as soon as one
created any order in a number field, the order (and hence also its parent
number field) would hang around for the rest of the Sage session, as an
entry in the cache of {{{absolute_order_from_module_generators}}}.
(Using {{{UniqueFactory}}} wouldn't solve this; it would cache weak
references so that orders could still be garbage collected, but these
weakrefs would be stored in a cache whose *keys* included the number
field, so the number field still couldn't be garbage collected.)
The best solution I can think of would be to store orders in a cache which
was itself an attribute of the parent number field. This could be
implemented by making {{{order}}} tuplify its arguments and then call a
second *method* {{{_order_from_cache}}}, implemented using
{{{@cached_method}}} as usual. Then the second method's cache is then an
attribute of the number field, and hence (a) there is no need to include
the number field in the arguments, and (b) the number field and the orders
can be garbage collected without problems. (This is what I suggested 5
weeks ago.)
On the other hand, this is all a bit theoretical, because of the issue at
ticket #715: it's basically impossible to get rid of *any* parent object
created in a Sage session, because the coercion model caches stuff all
over the place. But I think we shouldn't compound the problem further
here.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10448#comment:11>
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 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-trac?hl=en.