On Sunday 8 September 2024 at 13:18:40 UTC-7 marc....@gmail.com wrote: As I said above this does not happen with either cypari or cypari2 when using getno.
This is not a cypari issue. The issue is that Sage creates a "unique" object for each new number field, where new means that the input parameters for the NumberField function have not been used before. The number field objects are stored in a cache indexed by a key generated from the input parameters. Those cached objects live for the entire session. This is by design. The design did not anticipate creating a billion number fields in one Sage session. That was not necessarily a bad choice. Perhaps there is a way of disabling caching or clearing the cache. I don't think that number fields are designed to be immortal. They probably end up being that because of a combination of references in the coercion framework and the UniqueRepresentation store. The idea of UniqueRepresentation objects is that when an object is created *with the same creation parameters* as an object that already exists, then that identical object is returned. One main advantage (and originally one of the important reasons for introducing that design) is that equality can then be reduced to identity, which is a lightning-fast comparison. In the coercion framework this is quite important because arithmetic operations can easily end up in inner loops, so a fast path for deciding coercion doesn't need to do anything is important. Parent equality indicates this! The reference dictionary that keeps track of UniqueRepresentation objects by itself does NOT try to make the objects immortal: if a parent gets created and then loses all references, it should be garbage collectible, and many UniqueRepresentation objects are. Once the object is garbage collected, a new instance would be created. This is realized by using a WeakValueDictionary for the UniqueRepresentation storage: the global reference to the object held by the UniqueRepresentation constructor does not count towards the reference count. So if there are otherwise no references (or only other weak ones) the object becomes eligible for garbage collection. In practice, for such complicated objects (particularly objects that participate in the coercion framework), the reference count is very likely never zero. For one thing, rings generally cache their 0 and 1 and those elements hold a reference back to their parent. So parents almost always have to be garbage collected by the cycle-detecting mark-and-sweep. A classic example for how an object can become immortal through this process is if one of the construction parameters of an object ends up participating in a reference chain to the constructed object. This can happen through caching operations, for caches that are only intended to survive for the lifetime of the object. Now there is a global reference (held by the construction parameter that is stored in UniqueRepresentation) to the object , so the entry from the WeakValueDict is never removed. Normally this key info would get dereferenced once the value gets garbage collected, so those keys would normally not be immortal either. But the cycle prevents removal. There are other such side-effects of some of the global WeakValueDicts that are use, as well as the MonoDicts and TripleDicts used in the coercion framework. For UniqueRepresentation, it means one needs to be very disciplined about the way the construction parameters are stored. For the most part, these should be rather simple objects that cannot hold references to the kinds of objects that are instantiated from the parameters. But this is a very difficult and non-local thing to establish, so it's almost impossible to get programmers to adhere such discipline [partly because it's difficult to properly codify into simple-to-apply rules, and hence this hasn't been done]. -- 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ad214e52-23aa-45ed-a03b-1f5778f981bdn%40googlegroups.com.
