needs review.
--
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
On Sat, 1 Dec 2018, 'Martin R' via sage-devel wrote:
https://trac.sagemath.org/ticket/26794
I don't think that this is critical. The user never gets wrong answers
because of this.
Anyways, needs to be corrected. This is cython thing, not python. I'm not
familiar with cython, so maybe someo
https://trac.sagemath.org/ticket/26794
Am Samstag, 1. Dezember 2018 08:57:36 UTC+1 schrieb Martin R:
>
> OK, here is code that certainly leaks and confirms what you found, Jori.
> Congratulations!
>
> def check_bad5(n):
> """
OK, here is code that certainly leaks and confirms what you found, Jori.
Congratulations!
def check_bad5(n):
"""
sage: check_bad5(10)
On Fri, 30 Nov 2018, 'Martin R' via sage-devel wrote:
It seems to me that the following does NOT leak.
def check_bad4(n):
P = HasseDiagram(dig)
for i in range(n):
x = P.breadth_first_search(i)
You don't stop the search in first match, so the memory will be freed. T
I think it would be good to have a self-contained function that confirms
that breadth_first_search leaks.
It seems to me that the following does NOT leak.
def check_bad4(n):
from sage.graphs.digraph_generators import DiGraphGenerators
from sage.combinat.posets.hasse_diagram import HasseD
On Wed, 28 Nov 2018, 'Martin R' via sage-devel wrote:
Can you confirm that running check_bad3 above allocates memory without
limits?
Confirmed.
I got it: breadth_first_search (used in HasseDiagram.is_lequal) leaks.
if I use breadth_first_search(i, distance=self.cardinality()) instead, the l
On Wednesday, November 28, 2018 at 1:48:53 PM UTC-8, Nils Bruin wrote:
>
>
> I'm not sure this is the same memory problem the Martin originally
> stumbled on, because there I was not seeing large numbers of objects on the
> heap.
>
Hm, I must have done the original test on a different version of
On Wednesday, November 28, 2018 at 12:53:57 AM UTC-8, Jori Mäntysalo wrote:
>
> The code can be made a little shorter:
>
> def check(n):
> while True:
> for P in Posets(n):
> x = P._hasse_diagram.moebius_function(0, n-1)
> print get_memory_usage()
>
> It st
NEW MESSAGE:
I got it: breadth_first_search (used in HasseDiagram.is_lequal) leaks.
if I use breadth_first_search(i, distance=self.cardinality()) instead, the
leak is gone.
Martin
OLD MESSAGE:
I just tried with python3. The code runs. check_bad3(7) allocates roughly
0.5 megabytes per invo
Can you confirm that running check_bad3 above allocates memory without
limits?
Martin
Am Mittwoch, 28. November 2018 20:56:41 UTC+1 schrieb Jori Mäntysalo:
>
> On Wed, 28 Nov 2018, 'Martin R' via sage-devel wrote:
>
> > Thank you for looking into this. I think the problem exists also for
> th
On Wed, 28 Nov 2018, 'Martin R' via sage-devel wrote:
Thank you for looking into this. I think the problem exists also for the
following code, however only for n = 8:
I did some other tests too, but only got confused. Hasse diagrams are just
graphs, I think -- they are not derived from Uniqu
Thank you for looking into this. I think the problem exists also for the
following code, however only for n = 8:
def check_bad3(n):
from sage.graphs.digraph_generators import DiGraphGenerators
from sage.combinat.posets.hasse_diagram import HasseDiagram
for dig in DiGraphGenerators()(
On Sun, 25 Nov 2018, 'Martin R' via sage-devel wrote:
I still think that there is something odd going on. I do not understand the
following:
def check(n):
while True:
for P in Posets(n):
Q = P.with_bounds()
x = Q.moebius_function(Q.bottom(), Q.top())
I still think that there is something odd going on. I do not understand
the following:
def check(n):
while True:
for P in Posets(n):
Q = P.with_bounds()
x = Q.moebius_function(Q.bottom(), Q.top())
print get_memory_usage()
#
On Saturday, November 24, 2018 at 11:47:54 PM UTC-8, Martin R wrote:
>
> Yes, but should't that be released once the poset is thrown away?
>
> The following code:
import gc
from collections import Counter
gc.collect()
pre={id(c) for c in gc.get_objects()}
for P in posets(7):
Q = P.with_bounds
Yes, but should't that be released once the poset is thrown away?
Am Sonntag, 25. November 2018 08:41:50 UTC+1 schrieb Jori Mäntysalo:
>
> On Sat, 24 Nov 2018, 'Martin R' via sage-devel wrote:
>
> > I am running a big, but simple computation and running out of memory,
> but do
> > not understan
On Sat, 24 Nov 2018, 'Martin R' via sage-devel wrote:
I am running a big, but simple computation and running out of memory, but do
not understand why. I am pretty sure that the problem is in the computation
of the moebius function.
moebius_function() uses _moebius_function_values, which means
Dear memory experts!
I am running a big, but simple computation and running out of memory, but
do not understand why. I am pretty sure that the problem is in the
computation of the moebius function. Below is a silly minimal example,
together with some checks to make sure it's in moebius_functi
19 matches
Mail list logo
