Thanks for the workaround :) Another workaround is | == K(1) |.
Don't have a trac account. Note that modification of your workaround still leaks (probably this known/the same): if K(2)**(n-1)== 2 *K.one(): #leaks On Fri, Nov 15, 2013 at 02:42:36PM +0000, Simon King wrote: > Hi Georgi, > > On 2013-11-15, Georgi Guninski <[email protected]> wrote: > > Everyone knows sage has no bugs. > > OMG, this means I lost my main occupation! > > > Appears to me the following program should use > > O(1) memory. > > > > Watching memory usage in top(1), the proggie uses > > 3GB ram in less than a minute and memory usage > > increases constantly. > > There is supposed to be a slow increase, because the memory consumption > of IntegerModRing(n**2) depends on the size of n, if I am not mistaken. > > However, it seems that you are right, there is a leak. Even with the git > branch of trac ticket #15367 (that is supposed to fix some memory leak), > I obtain: > > sage: def wief(): > ....: n=2 > ....: while n<10**20: > ....: K=IntegerModRing(n**2) > ....: if K(2)**(n-1)==1: > ....: print n > ....: print n, get_memory_usage() > ....: n += 1 > sage: get_memory_usage() > 189.44140625 > sage: import gc > sage: _ = gc.collect() > sage: len(gc.get_objects()) > 94444 > sage: wief() > ... > 60275 563.58203125 > ^C--------------------------------------------------------------------------- > KeyboardInterrupt Traceback (most recent call last) > ... > sage: _ = gc.collect() > sage: len(gc.get_objects()) > 3775157 > > > While I am still using sage, is there a workaround > > for this ``feature''? > > If you do not do computations in your function "wief", but only create > the IntegerModRing, then the memory consumption is rather steady. Hence, > the fact that the memory consumption increases when doing computations > indicates that Sage's coercion framework is responsible for the leak. > > Do you have a trac account? Then please create a ticket and put me as > Cc. Otherwise I'll open a ticket myself. > > As a work-around, try this (I tested vanilla sage-5.13.beta2): > > sage: import gc > sage: _ = gc.collect() > sage: len(gc.get_objects()) > 114412 > sage: def wief(): > ....: n=2 > ....: while n<10**20: > ....: K=IntegerModRing(n**2) > ....: if K(2)**(n-1)==K.one(): > ....: print n > ....: print n, get_memory_usage() > ....: n += 1 > # <Ctrl-C> after more than 300,000 rounds > sage: _ = gc.collect() > sage: len(gc.get_objects()) > 115199 > > The difference is as follows: If you compare an element of K with the > integer "1", then Sage needs to compute a homomorphism from ZZ to K. > This homomorphism is cached for later use. We try to make the caching > that does not prevent unused rings from garbage collection. But it seems > you've hit an example where Sage fails. > > With the new version of the function, the memory consumption first > increases and then remains steady even for n>300,000. > > Best regards, > Simon > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/groups/opt_out.
