Is it intentional that number fields are not unique parents?

[Simon King]

Hi!

Resuming work on #10448, I found
sage: K.<z7> = QuadraticField(7)
sage: K is loads(dumps(K))
False

So, number fields are not unique parents.

This is in contrast to what David Loeffler claims in one comment of
the ticket:
"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."

My question: In what sense are number fields globally unique?
Aparently there is no UniqueFactory in the background. Should there be
one? Or is there the possibility that caching by UniqueFactory would
make things stay in memory for too long?

Cheers,
Simon

[William Stein]

On Fri, Mar 25, 2011 at 8:02 AM, Simon King <simon...@uni-jena.de> wrote:
> Hi!
>
> Resuming work on #10448, I found
>  sage: K.<z7> = QuadraticField(7)
>  sage: K is loads(dumps(K))
>  False
>
> So, number fields are not unique parents.
>
> This is in contrast to what David Loeffler claims in one comment of
> the ticket:
> "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."
>

He probably meant this:

sage: K.<z7> = QuadraticField(7)

sage: L.<z7> = QuadraticField(7)
sage: K is L
True

> My question: In what sense are number fields globally unique?

Evidently, at least the above.

> Aparently there is no UniqueFactory in the background. Should there be
> one?

I think probably so.

> Or is there the possibility that caching by UniqueFactory would
> make things stay in memory for too long?

I don't know if that is possible.

>
> Cheers,
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups "sage-nt" group.
> To post to this group, send an email to sag...@googlegroups.com.
> To unsubscribe from this group, send email to sage-nt+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-nt?hl=en-GB.
>
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[daveloeffler]

On Mar 25, 3:02 pm, Simon King <simon.k...@uni-jena.de> wrote:
> Hi!
>
> Resuming work on #10448, I found
>   sage: K.<z7> = QuadraticField(7)
>   sage: K is loads(dumps(K))
>   False
>
> So, number fields are not unique parents.
>
> This is in contrast to what David Loeffler claims in one comment of
> the ticket:
> "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."
>
> My question: In what sense are number fields globally unique?

I think that the way you exhibit here -- pickling and unpickling -- is
the *only* way to break non-uniqueness of number fields. As William
has just pointed out, if you try to create two number fields with the
same polynomial and variable name in a single Sage session, you'll end
up with two references to the same object.

> Aparently there is no UniqueFactory in the background. Should there be
> one? Or is there the possibility that caching by UniqueFactory would
> make things stay in memory for too long?

As far as I know, this is not achieved using a UniqueFactory simply
because Sage has been doing number fields since long before
UniqueFactories came along, and nobody felt like rewriting the number
field code to use the UniqueFactory class. (If it ain't broke, and all
that...) Similarly, the modular forms code has dozens of cached
methods that aren't @CachedMethods.

David

[Simon King]

Hi Dave and William!

On 1 Apr., 15:50, daveloeffler <dave.loeff...@gmail.com> wrote:
> ...

> As far as I know, this is not achieved using a UniqueFactory simply
> because Sage has been doing number fields since long before
> UniqueFactories came along, and nobody felt like rewriting the number
> field code to use the UniqueFactory class.

This is what I guessed.

Rewriting that would probably mean that loading a number field from an
old pickle and loading the same number field from a new pickle would
result in different objects. But since uniqueness is broken for
loading anyway, it may be worth trying.

I don't know when I will find the time to do so, ...

> Similarly, the modular forms code has dozens of cached
> methods that aren't @CachedMethods.

..., since currently I have different plans, one of them including to
provide a Cython version of @cached_method. First tests seem to
indicate that using @cached_method will result in faster access to the
cache than with a hand-written cached Python method.

Cheers,
Simon