Nice one…
Indeed:
sage: f.expand()(y=i)
-(3735/1394*I + 405/1394)*z^3 - (606/697*I - 942/697)*z^2 - (8681/6970*I +
15973/6970)*z + 1
sage: f.partial_fraction(y)(y=i)
-(3735/1394*I + 405/1394)*z^3 - (606/697*I - 942/697)*z^2 - (8681/6970*I +
15973/6970)*z + 1
sage: f.simplify_full()(y=i)
THis got solved really nicely
in
https://ask.sagemath.org/question/46123/arrow-length-goes-wild-near-poles-in-vector-field-plot/
I posted here because i can not easily post long tracebacks on the forum,
and i believed it was important for solving the problem. but it turns out
it was me
I can only agree with the original posting: Sage-6.6 release on gentoo
requires more than 1.5GB for compiling, on a 2GB computer about half a GB
is needed for running gnome (especially now that polkit has an unfixed
memory-leak in gentoo), so during single-threaded builds Swapfile will
Cython was using too much memory, should be fixed in recent beta.
On Monday, 4 May 2015 07:14:18 UTC-6, 94n...@gmail.com wrote:
I can only agree with the original posting: Sage-6.6 release on gentoo
requires more than 1.5GB for compiling, on a 2GB computer about half a GB
is needed for
On 2015-03-26 20:09, Volker Braun wrote:
Thats probably not enough for a parallel build. Try:
MAKE='make -j1' make
I don't think the original poster was using a parallel build (at least I
see no evidence of this).
--
You received this message because you are subscribed to the Google Groups
Thats probably not enough for a parallel build. Try:
MAKE='make -j1' make
On Thursday, March 26, 2015 at 7:30:58 PM UTC+1, bogda...@gmail.com wrote:
My computer runs out of memory when I attempt to build sage from source. I
want to build sage-6.6.rc0.
Installation log
Hi Simon,
You're completely right. Actually I messed up the libraries, the __call__
method used should be the one from Mpolynomial_libsingular.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving
Hi Gabriel,
On 2014-05-25, Gabriel Furstenheim Milerud furstenh...@gmail.com wrote:
There is a memory leak in the evaluation of multivariable polynomials:
-C.x,y,z=GF(2)[]
-f=x^4+x*y^3+z^6
-get_memory_usage()
.1014.47265625
- for i in xrange(100):
a=f(1,0,0)
Simon King wrote:
Hi Gabriel,
On 2014-05-25, Gabriel Furstenheim Milerud furstenh...@gmail.com wrote:
There is a memory leak in the evaluation of multivariable polynomials:
-C.x,y,z=GF(2)[]
-f=x^4+x*y^3+z^6
-get_memory_usage()
.1014.47265625
- for i in xrange(100):
a=f(1,0,0)
Thanks guys. Manual garbage collection helps, but memory usage still creeps up.
Looks like I need to build sage 6.2 from source!
--
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,
you can force a garbage collection with
import gc
gc.collect()
But your script doesn't increase memory on Sage-6.2.rc0 even without that.
On Wednesday, April 30, 2014 3:19:12 PM UTC+1, pete.d...@port.ac.uk wrote:
Hi all,
I'm pretty new to Python, so perhaps I'm doing something wrong, but
On Wednesday, April 30, 2014 7:19:12 AM UTC-7, pete.d...@port.ac.uk wrote:
Hi all,
I'm pretty new to Python, so perhaps I'm doing something wrong, but I've
encountered what I believe to be a memory leak in Sage's Cone.dual() method.
Below is some very simplified proof of concept code
Hello again !!!
This happens no matter if I use solver=GLPK or solver=coin (cbc is
installed), so it does not seem to be a problem of the underlying milp-
solver.
This was a mistake ! I actually forgot to free some memory in both of these
backends ! ;-)
The bug is fixed, though. It is
This happens no matter if I use solver=GLPK or solver=coin (cbc is
installed), so it does not seem to be a problem of the underlying milp-
solver.
Pompompom That's probably my fault :-D
I will try to deal with it today. I'll keep this thread updated :-)
Nathann
--
To post to
Hi!
On 3 Mai, 05:42, Alex Ghitza aghi...@gmail.com wrote:
...
I can see good reasons why we want the current behaviour of
uniqueness of parents, and what we just saw here is a good reason
why we might *not* want it. How can we reconcile this? Can we make
it easy to turn off uniqueness of
On May 2, 2009, at 11:48 PM, simon.k...@uni-jena.de wrote:
Hi!
On 3 Mai, 05:42, Alex Ghitza aghi...@gmail.com wrote:
...
I can see good reasons why we want the current behaviour of
uniqueness of parents, and what we just saw here is a good reason
why we might *not* want it. How can we
Hi!
On 3 Mai, 08:48, simon.k...@uni-jena.de wrote:
,,,
I think in this way one would have unique parents *and* would fix the
memory leak, but I am afraid I don't know enough about weak references
to implement it.
Thanks to google, I found how it works:
Replace the line
_cache = {}
in
PS:
One can then do
sage: for p in primes(2,100):
: R.x,y,z = GF(p)[]
sage: get_memory_usage()
778.35546875
And:
sage: len(sage.rings.polynomial.polynomial_ring_constructor._cache)
34
Hence, indeed, some rings were garbage collected.
Cheers,
Simon
On May 3, 12:28 am, simon.k...@uni-jena.de wrote:
Hi,
Is there any reason you opened a new ticket and did not use #5949 as
mentioned above?
PS:
One can then do
sage: for p in primes(2,100):
: R.x,y,z = GF(p)[]
sage: get_memory_usage()
778.35546875
And:
On May 3, 2009, at 1:04 AM, mabshoff wrote:
On May 3, 12:28 am, simon.k...@uni-jena.de wrote:
Hi,
Is there any reason you opened a new ticket and did not use #5949 as
mentioned above?
PS:
One can then do
sage: for p in primes(2,100):
: R.x,y,z = GF(p)[]
sage:
On May 3, 1:20 am, Robert Bradshaw rober...@math.washington.edu
wrote:
On May 3, 2009, at 1:04 AM, mabshoff wrote:
SNIP
As is this patch breaks badly:
Yep, see
http://trac.sagemath.org/sage_trac/ticket/3706
- Robert
Do you mean we need an analog fix? I have always been mistrustful
FYI: Simon's patch doesn't make any difference for the amount of
memory used for
sage: while p2^20:
: p=next_prime(p)
: g=FindGroupOrder(p,11)
:
In both cases about 2046MB more were used after the loop :(. Simon:
Run
init_mem=get_memory_usage()
before you do anything,
On Sun, May 3, 2009 at 6:33 PM, mabshoff
michael.absh...@mathematik.uni-dortmund.de wrote:
FYI: Simon's patch doesn't make any difference for the amount of
memory used for
sage: while p2^20:
: p=next_prime(p)
: g=FindGroupOrder(p,11)
:
In both cases about 2046MB
Hi Michael,
On 3 Mai, 10:04, mabshoff michael.absh...@mathematik.uni-dortmund.de
wrote:
Is there any reason you opened a new ticket and did not use #5949 as
mentioned above?
Yes. I did the patch before breakfast :)
If it is true that there is a problem with weak references in Cython
(what
On May 3, 1:54 am, Alex Ghitza aghi...@gmail.com wrote:
On Sun, May 3, 2009 at 6:33 PM, mabshoff
michael.absh...@mathematik.uni-dortmund.de wrote:
FYI: Simon's patch doesn't make any difference for the amount of
memory used for
sage: while p2^20:
: p=next_prime(p)
:
On May 3, 2:00 am, simon.k...@uni-jena.de wrote:
Hi Michael,
On 3 Mai, 10:04, mabshoff michael.absh...@mathematik.uni-dortmund.de
wrote:
Is there any reason you opened a new ticket and did not use #5949 as
mentioned above?
Yes. I did the patch before breakfast :)
:)
Overall it
When an elliptic curve is created the code in the __init__ function in
ell_generic.py (lines 164-5) do cause a multivariate polynomial ring
to be created. In this case it's a new ring each time as the base
field is always a new field.
The reason this is done is that the elliptic curve class
Dear John,
On 2 Mai, 18:39, John Cremona john.crem...@gmail.com wrote:
When an elliptic curve is created the code in the __init__ function in
ell_generic.py (lines 164-5) do cause a multivariate polynomial ring
to be created. In this case it's a new ring each time as the base
field is
On May 2, 5:55 pm, simon.k...@uni-jena.de wrote:
Dear John,
On 2 Mai, 18:39, John Cremona john.crem...@gmail.com wrote:
When an elliptic curve is created the code in the __init__ function in
ell_generic.py (lines 164-5) do cause a multivariate polynomial ring
to be created. In this
When an elliptic curve is created the code in the __init__ function in
ell_generic.py (lines 164-5) do cause a multivariate polynomial ring
to be created. In this case it's a new ring each time as the base
field is always a new field.
How is the multivariate polynomial ring
On May 2, 2009, at 8:42 PM, Alex Ghitza wrote:
When an elliptic curve is created the code in the __init__
function in
ell_generic.py (lines 164-5) do cause a multivariate polynomial
ring
to be created. In this case it's a new ring each time as the base
field is always a new field.
The actual cardinality is computed using the pari library (since the
field is a prime field and p10**18). I the leak is in libsingular it
must come from constructing the curve, not from computing the
cardinality. So it would be worth testing the loop with a new
function which constructs the
On May 1, 2:02 am, John Cremona john.crem...@gmail.com wrote:
Hi John,
The actual cardinality is computed using the pari library (since the
field is a prime field and p10**18). I the leak is in libsingular it
must come from constructing the curve, not from computing the
cardinality. So
On May 1, 2009, at 2:34 AM, mabshoff wrote:
On May 1, 2:02 am, John Cremona john.crem...@gmail.com wrote:
Hi John,
The actual cardinality is computed using the pari library (since the
field is a prime field and p10**18). I the leak is in
libsingular it
must come from constructing the
On May 1, 12:12 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
SNIP
No that I have a clue how to debug this, so I will poke RobertWB - I
am sure he has nothing better to do that to dive into this problem and
will be happy to debug this ;)
Yep, I bet coercion is leaking rings.
Michael,
Thanks for your reply.
I did the exact same thing under magma, and it consumes 14 meg.
Have you found anything new?
Regards,
Iram
On Apr 29, 9:07 pm, mabshoff michael.absh...@mathematik.uni-
dortmund.de wrote:
On Apr 29, 11:11 am, opti iram.che...@gmail.com wrote:
Hello,
Hi,
On Apr 30, 9:15 am, opti iram.che...@gmail.com wrote:
Michael,
Hi Iram,
Thanks for your reply.
I did the exact same thing under magma, and it consumes 14 meg.
Hehe, you know how to get us going :)
Have you found anything new?
I did find the cause, but I have not found a fix yet. What
On Apr 29, 11:11 am, opti iram.che...@gmail.com wrote:
Hello,
Hi,
I am using sage 3.4
I have written a simple sage script to evalute the cardinal of Brent-
Suyama elliptic curves s=11
for primes 2^27.
Memory usage increases till program (or machine) crashes.
The script is the
38 matches
Mail list logo
