On Wednesday, May 28, 2014 10:51:10 AM UTC-7, vdelecroix wrote:
> For me, it would makes sense on parents directly
> {{{
> sage: Permutations().known_maps_to(Partitions())
> [...]
> }}}
> And in the methods known_maps_to and known_maps_from there should be
> pointer on how to feed the database with more maps. But I would charge
> the elements with that.
>
You'd want to be very careful with putting cross references between
(global) objects and/or storing objects in global dictionaries. Such links
nearly always have memory footprint and object lifetime implications. It's
terribly easy to make decisions that seem reasonable for your own usage,
but lead to ever-increasing memory use (aka "memory leak") for another,
entirely reasonable usage scenario. A recent example is
http://trac.sagemath.org/ticket/15801, where it was found that a relatively
natural thing to do: realizing, say, algebras over finite fields as living
in categories "algebras over F_q" turns out to have very bad consequences:
People can easily construct algebras over many different finite fields, and
categories remain in memory forever (they were designed with the idea their
number is uniformly bounded in time--which turns out to be a false
assumption if you allow categories parametrized by base)
It may well be that for your database purposes you DO want to register
things globally somewhere, but almost certainly you cannot do so by default.
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
