[sage-devel] Re: xgcd hangs forever (flint?)
I can confirm that this happens with the flint interpreter (Nemo) as well.
So it is almost certainly a flint bug.
I'll open a ticket for it now and take a quick look to see if it is
something simple.
Bill.
On Tuesday, 27 January 2015 02:41:18 UTC+1, vdelecroix wrote:
>
> Hello,
>
> As I was working on #17671, it appears that I found a rather strange bug
> {{{
> sage: R. = ZZ[]
> sage: R(2).xgcd(R(2)) # you will have to wait after that!!
> }}}
> I opened #17675 for the issue. From the implementation of xgcd it
> seems to me that it is related to flint but I might be wrong.
>
> Vincent
>
--
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.
[sage-devel] Re: xgcd hangs forever (flint?)
This turns out not to be a bug.
The documentation requires that the inputs be primitive, which in the
example given, they aren't. The function does work if passed the
polynomials R(1) and R(1).
However, this bug also exists in Nemo. So thanks for pointing it out. I can
fix that, at least.
Bill.
On Tuesday, 27 January 2015 16:04:14 UTC+1, Bill Hart wrote:
>
> I can confirm that this happens with the flint interpreter (Nemo) as well.
> So it is almost certainly a flint bug.
>
> I'll open a ticket for it now and take a quick look to see if it is
> something simple.
>
> Bill.
>
> On Tuesday, 27 January 2015 02:41:18 UTC+1, vdelecroix wrote:
>>
>> Hello,
>>
>> As I was working on #17671, it appears that I found a rather strange bug
>> {{{
>> sage: R. = ZZ[]
>> sage: R(2).xgcd(R(2)) # you will have to wait after that!!
>> }}}
>> I opened #17675 for the issue. From the implementation of xgcd it
>> seems to me that it is related to flint but I might be wrong.
>>
>> Vincent
>>
>
--
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.
Re: [sage-devel] Re: xgcd hangs forever (flint?)
Hi Bill, 2015-01-27 16:16 UTC+01:00, Bill Hart : > This turns out not to be a bug. > > The documentation requires that the inputs be primitive, which in the > example given, they aren't. The function does work if passed the > polynomials R(1) and R(1). I see. Thanks I will update the trac ticket and the way we use the function. > However, this bug also exists in Nemo. So thanks for pointing it out. I can > > fix that, at least. Do you mean that you will change the specification of the FLINT function or that you will only modify Nemo ? Vincent -- 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.
Re: [sage-devel] Re: xgcd hangs forever (flint?)
For the time being I'm just going to modify Nemo. It would probably be inefficient to do anything else. On Tuesday, 27 January 2015 16:22:39 UTC+1, vdelecroix wrote: > > Hi Bill, > > 2015-01-27 16:16 UTC+01:00, Bill Hart >: > > This turns out not to be a bug. > > > > The documentation requires that the inputs be primitive, which in the > > example given, they aren't. The function does work if passed the > > polynomials R(1) and R(1). > > I see. Thanks I will update the trac ticket and the way we use the > function. > > > However, this bug also exists in Nemo. So thanks for pointing it out. I > can > > > > fix that, at least. > > Do you mean that you will change the specification of the FLINT > function or that you will only modify Nemo ? > > Vincent > -- 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.
Re: [sage-devel] Re: xgcd hangs forever (flint?)
I remember the problem now. resultant(R(2), R(2)) = 1 since it is an empty product. But there is no Z-linear combination of R(2) and R(2) which gives 1. So the input has to be disallowed. It's only a problem for constant polynomial inputs that are not coprime (as elements of Z) though. For higher degrees there are powers of the contents that the polynomials can be multiplied by that will work. On Tuesday, 27 January 2015 16:28:46 UTC+1, Bill Hart wrote: > > For the time being I'm just going to modify Nemo. It would probably be > inefficient to do anything else. > > On Tuesday, 27 January 2015 16:22:39 UTC+1, vdelecroix wrote: >> >> Hi Bill, >> >> 2015-01-27 16:16 UTC+01:00, Bill Hart : >> > This turns out not to be a bug. >> > >> > The documentation requires that the inputs be primitive, which in the >> > example given, they aren't. The function does work if passed the >> > polynomials R(1) and R(1). >> >> I see. Thanks I will update the trac ticket and the way we use the >> function. >> >> > However, this bug also exists in Nemo. So thanks for pointing it out. I >> can >> > >> > fix that, at least. >> >> Do you mean that you will change the specification of the FLINT >> function or that you will only modify Nemo ? >> >> Vincent >> > -- 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.
Re: [sage-devel] Re: xgcd hangs forever (flint?)
Then it will be much simpler to adapt. Could you update the specification of the function in the FLINT documentation then? Vincent 2015-01-27 16:51 UTC+01:00, Bill Hart : > I remember the problem now. > > resultant(R(2), R(2)) = 1 > > since it is an empty product. > > But there is no Z-linear combination of R(2) and R(2) which gives 1. So the > > input has to be disallowed. > > It's only a problem for constant polynomial inputs that are not coprime (as > > elements of Z) though. For higher degrees there are powers of the contents > that the polynomials can be multiplied by that will work. > > On Tuesday, 27 January 2015 16:28:46 UTC+1, Bill Hart wrote: >> >> For the time being I'm just going to modify Nemo. It would probably be >> inefficient to do anything else. >> >> On Tuesday, 27 January 2015 16:22:39 UTC+1, vdelecroix wrote: >>> >>> Hi Bill, >>> >>> 2015-01-27 16:16 UTC+01:00, Bill Hart : >>> > This turns out not to be a bug. >>> > >>> > The documentation requires that the inputs be primitive, which in the >>> > example given, they aren't. The function does work if passed the >>> > polynomials R(1) and R(1). >>> >>> I see. Thanks I will update the trac ticket and the way we use the >>> function. >>> >>> > However, this bug also exists in Nemo. So thanks for pointing it out. I >>> > >>> can >>> > >>> > fix that, at least. >>> >>> Do you mean that you will change the specification of the FLINT >>> function or that you will only modify Nemo ? >>> >>> Vincent >>> >> > > -- > 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. > -- 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.
Re: [sage-devel] Re: xgcd hangs forever (flint?)
I'm not sure what you mean. The flint documentation already disallows this case. It can only occur when there is nontrivial content. This is presumably why it is disallowed in flint's xgcd function. On Tuesday, 27 January 2015 17:11:35 UTC+1, vdelecroix wrote: > > Then it will be much simpler to adapt. Could you update the > specification of the function in the FLINT documentation then? > > Vincent > > 2015-01-27 16:51 UTC+01:00, Bill Hart >: > > I remember the problem now. > > > > resultant(R(2), R(2)) = 1 > > > > since it is an empty product. > > > > But there is no Z-linear combination of R(2) and R(2) which gives 1. So > the > > > > input has to be disallowed. > > > > It's only a problem for constant polynomial inputs that are not coprime > (as > > > > elements of Z) though. For higher degrees there are powers of the > contents > > that the polynomials can be multiplied by that will work. > > > > On Tuesday, 27 January 2015 16:28:46 UTC+1, Bill Hart wrote: > >> > >> For the time being I'm just going to modify Nemo. It would probably be > >> inefficient to do anything else. > >> > >> On Tuesday, 27 January 2015 16:22:39 UTC+1, vdelecroix wrote: > >>> > >>> Hi Bill, > >>> > >>> 2015-01-27 16:16 UTC+01:00, Bill Hart : > >>> > This turns out not to be a bug. > >>> > > >>> > The documentation requires that the inputs be primitive, which in > the > >>> > example given, they aren't. The function does work if passed the > >>> > polynomials R(1) and R(1). > >>> > >>> I see. Thanks I will update the trac ticket and the way we use the > >>> function. > >>> > >>> > However, this bug also exists in Nemo. So thanks for pointing it > out. I > >>> > > >>> can > >>> > > >>> > fix that, at least. > >>> > >>> Do you mean that you will change the specification of the FLINT > >>> function or that you will only modify Nemo ? > >>> > >>> Vincent > >>> > >> > > > > -- > > 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+...@googlegroups.com . > > To post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
Re: [sage-devel] Re: xgcd hangs forever (flint?)
I meant: "The function assumes that f or g is not constant" instead of "both primitive". As far as I understand, this is the only case where something is broken, isn't it? 2015-01-27 17:20 UTC+01:00, Bill Hart : > I'm not sure what you mean. The flint documentation already disallows this > case. It can only occur when there is nontrivial content. This is > presumably why it is disallowed in flint's xgcd function. > > On Tuesday, 27 January 2015 17:11:35 UTC+1, vdelecroix wrote: >> >> Then it will be much simpler to adapt. Could you update the >> specification of the function in the FLINT documentation then? >> >> Vincent >> >> 2015-01-27 16:51 UTC+01:00, Bill Hart > >: >> > I remember the problem now. >> > >> > resultant(R(2), R(2)) = 1 >> > >> > since it is an empty product. >> > >> > But there is no Z-linear combination of R(2) and R(2) which gives 1. So >> > >> the >> > >> > input has to be disallowed. >> > >> > It's only a problem for constant polynomial inputs that are not coprime >> > >> (as >> > >> > elements of Z) though. For higher degrees there are powers of the >> contents >> > that the polynomials can be multiplied by that will work. >> > >> > On Tuesday, 27 January 2015 16:28:46 UTC+1, Bill Hart wrote: >> >> >> >> For the time being I'm just going to modify Nemo. It would probably be >> >> >> >> inefficient to do anything else. >> >> >> >> On Tuesday, 27 January 2015 16:22:39 UTC+1, vdelecroix wrote: >> >>> >> >>> Hi Bill, >> >>> >> >>> 2015-01-27 16:16 UTC+01:00, Bill Hart : >> >>> > This turns out not to be a bug. >> >>> > >> >>> > The documentation requires that the inputs be primitive, which in >> the >> >>> > example given, they aren't. The function does work if passed the >> >>> > polynomials R(1) and R(1). >> >>> >> >>> I see. Thanks I will update the trac ticket and the way we use the >> >>> function. >> >>> >> >>> > However, this bug also exists in Nemo. So thanks for pointing it >> out. I >> >>> > >> >>> can >> >>> > >> >>> > fix that, at least. >> >>> >> >>> Do you mean that you will change the specification of the FLINT >> >>> function or that you will only modify Nemo ? >> >>> >> >>> Vincent >> >>> >> >> >> > >> > -- >> > 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+...@googlegroups.com . >> > To post to this group, send email to sage-...@googlegroups.com >> . >> > Visit this group at http://groups.google.com/group/sage-devel. >> > For more options, visit https://groups.google.com/d/optout. >> > >> > > -- > 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. > -- 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.
[sage-devel] xgcd(2.0, 6.0)
Hello,
One last thing about xgcd. We currently have
{{{
sage: xgcd(2.0, 6.0)
2
sage: xgcd(2.0, 6.0).parent()
Integer Ring
}}}
I would like it to be changed in
{{{
sage: xgcd(2.0, 6.0)
1.0
sage: xgcd(2.0, 6.0).parent()
Real Field with 53 bits of precision
}}}
If anybody feels like we should not break the backward compatibility
here please tell me now... otherwise it will be changed in #17671.
Vincent
--
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.
Re: [sage-devel] Massive slowdown in ring inverses
I ran the same code with cProfile. Here's the output:
perron:sage5 svanzwam$ ./sage/sage speedtest.sage
Sage Version 5.12, Release Date: 2013-10-07
(0, 3, 1, 0, 2, 1)
7193816 function calls (7193814 primitive calls) in 3.425 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.4520.4523.4253.425 :2()
50.0000.0000.0000.000
category.py:1357(is_subcategory)
10.0000.0000.0000.000 category.py:1466(_meet_)
10.0000.0000.0000.000
category.py:2248(is_subcategory)
40.0000.0000.0000.000
category.py:666(_subcategory_hook_)
20.0000.0000.0000.000
dynamic_class.py:122(dynamic_class)
70.0000.0000.0000.000
finite_field_prime_modn.py:100(__cmp__)
10.0000.0000.0000.000
finite_field_prime_modn.py:153(_coerce_map_from_)
30.0000.0000.0000.000
finite_field_prime_modn.py:262(order)
20.0000.0000.0000.000 homset.py:410(__init__)
20.0000.0000.0000.000 homset.py:773(domain)
20.0000.0000.0000.000 homset.py:789(codomain)
4/20.0000.0000.0000.000 homset.py:83(Hom)
10.0000.0000.0000.000
integer_mod_ring.py:894(_element_constructor_)
10.0000.0000.0000.000
product_ring.py:145(_coerce_map_from_)
70.0000.0000.0000.000 product_ring.py:152()
5924240.8650.0000.9820.000 product_ring.py:154()
846320.1710.0001.1940.000 product_ring.py:154()
4231520.1780.0000.1780.000 product_ring.py:17(__init__)
10.0000.0000.0000.000 product_ring.py:28(_repr_)
70.0000.0000.0000.000 product_ring.py:32()
846300.0270.0000.0600.000 product_ring.py:34(__cmp__)
1692600.3590.0000.8220.000 product_ring.py:40(_add_)
11848200.2580.0000.3320.000 product_ring.py:46()
846300.1910.0000.4360.000 product_ring.py:56(_mul_)
5924100.1350.0000.1760.000 product_ring.py:62()
846300.2010.0000.4610.000 product_ring.py:64(_div_)
5924100.1400.0000.1870.000 product_ring.py:70()
20.0000.0000.0000.000
sets_cat.py:286(_element_constructor_)
500.0000.0000.0000.000 weakref.py:223(__new__)
320.0000.0000.0000.000 weakref.py:228(__init__)
20.0000.0000.0000.000 weakref.py:55(__getitem__)
10.0000.0000.0000.000 {all}
500.0000.0000.0000.000 {built-in method __new__ of
type object at 0x107cfc560}
846370.0340.0000.0340.000 {cmp}
20.0000.0000.0000.000 {hasattr}
110.0000.0000.0000.000 {isinstance}
40.0000.0000.0000.000 {issubclass}
10155600.0730.0000.0730.000 {method '_add_' of
'sage.rings.finite_rings.integer_mod.IntegerMod_int' objects}
5077800.0460.0000.0460.000 {method '_div_' of
'sage.rings.finite_rings.integer_mod.IntegerMod_int' objects}
5077800.0410.0000.0410.000 {method '_mul_' of
'sage.rings.finite_rings.integer_mod.IntegerMod_int' objects}
60.0000.0000.0000.000 {method '_repr_' of
'sage.rings.finite_rings.integer_mod.IntegerMod_abstract' objects}
40.0000.0000.0000.000 {method 'category' of
'sage.rings.ring.Ring' objects}
40.0000.0000.0000.000 {method 'category' of
'sage.structure.parent.Parent' objects}
5077920.1170.0000.1170.000 {method 'coerce_map_from' of
'sage.structure.parent.Parent' objects}
10.0000.0000.0000.000 {method 'disable' of
'_lsprof.Profiler' objects}
60.0000.0000.0000.000 {method 'has_coerce_map_from'
of 'sage.structure.parent.Parent' objects}
10.0000.0000.0000.000 {method 'join' of 'str'
objects}
3385200.0240.0000.0240.000 {method 'parent' of
'sage.structure.element.Element' objects}
10.0000.0000.0000.000
{sage.rings.finite_rings.integer_mod.IntegerMod}
3385200.1130.0000.1130.000 {zip}
perron:sage5 svanzwam$ ../sage/sage speedtest.sage
Sage Version 6.5.beta5, Release Date: 2015-01-05
(0, 3, 1, 0, 2, 1)
33598994 function calls (33598992 primitive calls) in 47.614
seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.6980.698 47.614 47.614 :2()
20.0000.0000.0000.000
category.py:1758(is_subcategory)
10.0000.0000.0000.000 category.py:1877
Re: [sage-devel] Re: xgcd hangs forever (flint?)
No, the function does actually genuinely assume that the inputs are primitive. In Nemo, I simply disallowed the case of constant inputs. For the non-primitive case there's a little more work to be done. Specifically if content(a) = c1 and content(b) = c2 then if fmpz_poly_bezout(primitive_part(a), primitive_part(b)) returns r, s, t you want to return r*c1^(length(b) - 1)*c2^(length(a) - 1), s*c1^(length(b) - 2)*c2^(length(a) - 1), t*c1^(length(b) - 1)*c2^(length(a) - 2), I believe. Bill. On Tuesday, 27 January 2015 17:53:18 UTC+1, vdelecroix wrote: > > I meant: "The function assumes that f or g is not constant" instead of > "both primitive". As far as I understand, this is the only case where > something is broken, isn't it? > > 2015-01-27 17:20 UTC+01:00, Bill Hart >: > > I'm not sure what you mean. The flint documentation already disallows > this > > case. It can only occur when there is nontrivial content. This is > > presumably why it is disallowed in flint's xgcd function. > > > > On Tuesday, 27 January 2015 17:11:35 UTC+1, vdelecroix wrote: > >> > >> Then it will be much simpler to adapt. Could you update the > >> specification of the function in the FLINT documentation then? > >> > >> Vincent > >> > >> 2015-01-27 16:51 UTC+01:00, Bill Hart >> >: > >> > I remember the problem now. > >> > > >> > resultant(R(2), R(2)) = 1 > >> > > >> > since it is an empty product. > >> > > >> > But there is no Z-linear combination of R(2) and R(2) which gives 1. > So > >> > > >> the > >> > > >> > input has to be disallowed. > >> > > >> > It's only a problem for constant polynomial inputs that are not > coprime > >> > > >> (as > >> > > >> > elements of Z) though. For higher degrees there are powers of the > >> contents > >> > that the polynomials can be multiplied by that will work. > >> > > >> > On Tuesday, 27 January 2015 16:28:46 UTC+1, Bill Hart wrote: > >> >> > >> >> For the time being I'm just going to modify Nemo. It would probably > be > >> >> > >> >> inefficient to do anything else. > >> >> > >> >> On Tuesday, 27 January 2015 16:22:39 UTC+1, vdelecroix wrote: > >> >>> > >> >>> Hi Bill, > >> >>> > >> >>> 2015-01-27 16:16 UTC+01:00, Bill Hart : > >> >>> > This turns out not to be a bug. > >> >>> > > >> >>> > The documentation requires that the inputs be primitive, which in > >> the > >> >>> > example given, they aren't. The function does work if passed the > >> >>> > polynomials R(1) and R(1). > >> >>> > >> >>> I see. Thanks I will update the trac ticket and the way we use the > >> >>> function. > >> >>> > >> >>> > However, this bug also exists in Nemo. So thanks for pointing it > >> out. I > >> >>> > > >> >>> can > >> >>> > > >> >>> > fix that, at least. > >> >>> > >> >>> Do you mean that you will change the specification of the FLINT > >> >>> function or that you will only modify Nemo ? > >> >>> > >> >>> Vincent > >> >>> > >> >> > >> > > >> > -- > >> > 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+...@googlegroups.com . > >> > To post to this group, send email to sage-...@googlegroups.com > >> . > >> > Visit this group at http://groups.google.com/group/sage-devel. > >> > For more options, visit https://groups.google.com/d/optout. > >> > > >> > > > > -- > > 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+...@googlegroups.com . > > To post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
Re: [sage-devel] Massive slowdown in ring inverses
Interesting. Note that the :2 () part actually comes
from hashing... as hash is defined by the wonderful
def __hash__(self):
return hash(str(self))
I am not so sure why there is much more call to has than before.
Vincent
2015-01-27 18:23 UTC+01:00, Stefan :
> I ran the same code with cProfile. Here's the output:
>
> perron:sage5 svanzwam$ ./sage/sage speedtest.sage
> Sage Version 5.12, Release Date: 2013-10-07
> (0, 3, 1, 0, 2, 1)
> 7193816 function calls (7193814 primitive calls) in 3.425 seconds
>
>Ordered by: standard name
>
>ncalls tottime percall cumtime percall filename:lineno(function)
> 10.4520.4523.4253.425 :2()
> 50.0000.0000.0000.000
> category.py:1357(is_subcategory)
> 10.0000.0000.0000.000 category.py:1466(_meet_)
> 10.0000.0000.0000.000
> category.py:2248(is_subcategory)
> 40.0000.0000.0000.000
> category.py:666(_subcategory_hook_)
> 20.0000.0000.0000.000
> dynamic_class.py:122(dynamic_class)
> 70.0000.0000.0000.000
> finite_field_prime_modn.py:100(__cmp__)
> 10.0000.0000.0000.000
> finite_field_prime_modn.py:153(_coerce_map_from_)
> 30.0000.0000.0000.000
> finite_field_prime_modn.py:262(order)
> 20.0000.0000.0000.000 homset.py:410(__init__)
> 20.0000.0000.0000.000 homset.py:773(domain)
> 20.0000.0000.0000.000 homset.py:789(codomain)
> 4/20.0000.0000.0000.000 homset.py:83(Hom)
> 10.0000.0000.0000.000
> integer_mod_ring.py:894(_element_constructor_)
> 10.0000.0000.0000.000
> product_ring.py:145(_coerce_map_from_)
> 70.0000.0000.0000.000
> product_ring.py:152()
>5924240.8650.0000.9820.000
> product_ring.py:154()
> 846320.1710.0001.1940.000 product_ring.py:154()
>4231520.1780.0000.1780.000 product_ring.py:17(__init__)
> 10.0000.0000.0000.000 product_ring.py:28(_repr_)
> 70.0000.0000.0000.000 product_ring.py:32()
> 846300.0270.0000.0600.000 product_ring.py:34(__cmp__)
>1692600.3590.0000.8220.000 product_ring.py:40(_add_)
> 11848200.2580.0000.3320.000 product_ring.py:46()
> 846300.1910.0000.4360.000 product_ring.py:56(_mul_)
>5924100.1350.0000.1760.000 product_ring.py:62()
> 846300.2010.0000.4610.000 product_ring.py:64(_div_)
>5924100.1400.0000.1870.000 product_ring.py:70()
> 20.0000.0000.0000.000
> sets_cat.py:286(_element_constructor_)
>500.0000.0000.0000.000 weakref.py:223(__new__)
>320.0000.0000.0000.000 weakref.py:228(__init__)
> 20.0000.0000.0000.000 weakref.py:55(__getitem__)
> 10.0000.0000.0000.000 {all}
>500.0000.0000.0000.000 {built-in method __new__ of
> type object at 0x107cfc560}
> 846370.0340.0000.0340.000 {cmp}
> 20.0000.0000.0000.000 {hasattr}
>110.0000.0000.0000.000 {isinstance}
> 40.0000.0000.0000.000 {issubclass}
> 10155600.0730.0000.0730.000 {method '_add_' of
> 'sage.rings.finite_rings.integer_mod.IntegerMod_int' objects}
>5077800.0460.0000.0460.000 {method '_div_' of
> 'sage.rings.finite_rings.integer_mod.IntegerMod_int' objects}
>5077800.0410.0000.0410.000 {method '_mul_' of
> 'sage.rings.finite_rings.integer_mod.IntegerMod_int' objects}
> 60.0000.0000.0000.000 {method '_repr_' of
> 'sage.rings.finite_rings.integer_mod.IntegerMod_abstract' objects}
> 40.0000.0000.0000.000 {method 'category' of
> 'sage.rings.ring.Ring' objects}
> 40.0000.0000.0000.000 {method 'category' of
> 'sage.structure.parent.Parent' objects}
>5077920.1170.0000.1170.000 {method 'coerce_map_from' of
> 'sage.structure.parent.Parent' objects}
> 10.0000.0000.0000.000 {method 'disable' of
> '_lsprof.Profiler' objects}
> 60.0000.0000.0000.000 {method 'has_coerce_map_from'
>
> of 'sage.structure.parent.Parent' objects}
> 10.0000.0000.0000.000 {method 'join' of 'str'
> objects}
>3385200.0240.0000.0240.000 {method 'parent' of
> 'sage.structure.element.Element' objects}
> 10.0000.0000.0000.000
> {sage.rings.finite_rings.integer_mod.IntegerMod}
>3385200.1130.0000.1130.000 {zip}
>
>
> perron:sage5 svanzwam$ ../sage/sage speedtest.sage
> Sage Version 6.
Re: [sage-devel] Massive slowdown in ring inverses
On Tuesday, January 27, 2015 at 10:05:02 AM UTC-8, vdelecroix wrote: > > Interesting. Note that the :2 () part actually comes > from hashing... Why do you think that? According to the profiling, this gets called only once, has a modest "total" time and a large variation in the "cumulative". I think that line is just the scope of the routine directly called in the profiling session (i.e., "top level"). The big difference that stands out to me is: 1015588/10155869.8160.000 33.7060.000 homset.py:86(Hom) versus 4/20.0000.0000.0000.000 homset.py:83(Hom) It suggests there is a homset that gets created and forgotten every time. You should probably dig into the callgraph to see who is triggering this call. It suggests to me that between 5.12 and 6.4, some memory leak in Hom caching was resolved. In your particular case it suggests that you may now have to do some extra work to keep the relevant homset alive (or some other object that needs it). -- 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.
Re: [sage-devel] "Can We Trust Computer Algebra Systems?"
I wrote
> I'm aware of this("stopgame" framework); it is a good start. AFAIK it does
> not support 'stopgame' at function level, only at package level.
>
This statement was of course completely wrong.
@William
why did you not blame me for that?
You can see 52 tickets involving it here:
>
>http://trac.sagemath.org/search?q=stopgap
>
If you know of *anything* that should be added, contributions are
> greatly welcome.
>
a first step:
http://trac.sagemath.org/search?q=stopgap+jakob
Jakob
--
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.
[sage-devel] Re: Massive slowdown in ring inverses
Hi Nils, On 2015-01-27, Nils Bruin wrote: > It suggests there is a homset that gets created and forgotten every time. > You should probably dig into the callgraph to see who is triggering this > call. It suggests to me that between 5.12 and 6.4, some memory leak in Hom > caching was resolved. In your particular case it suggests that you may now > have to do some extra work to keep the relevant homset alive (or some other > object that needs it). Yes, that sounds reasonable. We did a *lot* of effort to make it possible that homsets can be forgotten, to prevent memory leaks. Now, it should be the case that you need a strong reference to both domain and codomain to keep the homset alive (or a strong reference to the homset itself, of course). And concerning strong reference to (co-)domain: Many constructors are cached, but that is a *weak* cache. Best regards, Simon -- 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.
