On Monday, October 27, 2014 10:45:40 PM UTC, Nils Bruin wrote:
>
> In general I expect that cached_methods should preprocess their arguments 
> a bit before doing a key lookup anyway (such as do the required coercions 
> on arguments). Most of the time, functions with arguments should *not* be 
> cached, because their cache quickly becomes a memory leak.
>

I tend to disagree, IMHO this should just be handled better by the caching 
framework. For example, have a strong LRU cache of a certain size, and 
expire older results into a weakly referenced cache. With optional 
arguments to tune the LRU size etc.

But the most important thing is that caching must be 100% reliable, and 
that means input must be really equal (at most up to some unique 
isomorphism), and not just "equal enough". So either we make __eq__ much 
stricter, or we write our own associative container that doesn't use __eq__ 
to compare inputs.  The _cache_key() convention in #16316 is a baby step in 
that direction, except that it does it only for caching and doesn't provide 
a generally usable associative container. Eg. you'd essentially have to 
write your own hash table for Buchberger just for padics.

It seems that there could be three versions of associative containers 
(dict, set)

1) Python version. Randomly wrong if you add elements from different 
parents. 

2) A version coercing to a common parent (similar to Sequence)

The first two are insertion-order dependent on same parent with overly 
loose == comparison.

3) A version that treats elements from different parents as distinct before 
even calling ==, and with a hook to override == with a stricter comparison. 
This is what caching needs to use.


-- 
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.

Reply via email to