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 w
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.
Bil
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
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 requir
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 hi
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 com
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
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. I
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 br
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 perca
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
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 wit
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
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:
>
>
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.
15 matches
Mail list logo
