#715: Parents probably not reclaimed due to too much caching
-------------------------------------------------------------------+--------
Reporter: robertwb |
Owner: somebody
Type: defect |
Status: needs_review
Priority: major |
Milestone: sage-5.4
Component: coercion |
Resolution:
Keywords: weak cache coercion Cernay2012 | Work
issues:
Report Upstream: N/A |
Reviewers: Jean-Pierre Flori, Simon King, Nils Bruin
Authors: Simon King, Jean-Pierre Flori | Merged
in:
Dependencies: #9138, #11900, #11599, to be merged with #11521 |
Stopgaps:
-------------------------------------------------------------------+--------
Comment (by SimonKing):
If the test is
{{{
sage: @cached_function
... def oddprime_factors(n):
... l = [p for p,e in factor(n) if p != 2]
... return len(l)
sage: oddprime_factors.precompute(range(1,99), 4)
sage: oddprime_factors.cache[(25,),()]
1
}}}
then `sage -t` passes. A precomputation in `range(1,90)` or `range(1,50)`
or `range(2,100)` works as well. But if the precomputation runs in
`range(1,100)` or `range(2,101)` or `range(1,110)`, then there is signal
11.
Hence, it really seems that we located the culprit - although I have no
idea whatsoever as to what is happening here. It seems that there is no
error, if we precompute at most 98 values, but if we have 99 or more
precomputed value then there is signal 11.
Any idea what to try next?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:244>
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.
