I wonder if it is possible to recreate the problem just using FLINT,
without any Sage, i.e. just write a short FLINT program which
replicates the problem.
I don't understand how the multiplication could take any serious
quantity of time unless the pow was screwed up somehow. But perhaps it
is.
On Jan 29, 10:13 am, Bill Hart goodwillh...@googlemail.com wrote:
I wonder if it is possible to recreate the problem just using FLINT,
without any Sage, i.e. just write a short FLINT program which
replicates the problem.
I don't understand how the multiplication could take any serious
Not that I can think of at the moment.
Sometimes these bugs can be terribly subtle. The other day I tracked
down a bug in FLINT's F_mpz_div_2exp on 32 bit machines. In the end I
found the following code gave the wrong answer:
ulong a = 573498595893479UL;
ulong b = 42;
printf(%lu\n, ab);
The
I think there might have been some progress:
sage: R.x = QQ[]
sage: f = 3/2*x - 1/3
sage: _ = f % f
Begin: fmpz_poly_pseudo_divrem(quo, r.num, m, a.num, b.num)
a.num = 9*t-2
fmpz_poly_length(a.num) = 2
fmpz_poly_max_limbs(a.num) = 1
b.num = 9*t-2
fmpz_poly_length(b.num) = 2
On Fri, Jan 29, 2010 at 05:58:39AM -0800, Sebastian Pancratz wrote:
The value of m is set by the call fmpz_poly_pseudo_divrem(quo, r.num,
m, a.num, b.num), where as the output above shows we have a.num and
b.num both equal the polynomial 9*t-2. From the FLINT (1.5.0) manual,
this call should
On Jan 29, 2:22 pm, Willem Jan Palenstijn w...@usecode.org wrote:
On Fri, Jan 29, 2010 at 05:58:39AM -0800, Sebastian Pancratz wrote:
The value of m is set by the call fmpz_poly_pseudo_divrem(quo, r.num,
m, a.num, b.num), where as the output above shows we have a.num and
b.num both equal
Thanks Willem. That's just a really silly bug on my part. I presume I
have been very naughty and not written test code for
fmpz_poly_pseudo_divrem. I mean, what can possibly go wrong with a cut
and paste. :-)
By the way, fmpz_poly_pseudo_rem should be faster if you don't require
the quotient.
By the way, fmpz_poly_pseudo_rem should be faster if you don't require
the quotient.
Bill.
I originally wrote the Cython code against FLINT 1.4.0 and at the time
there was a bug in fmpz_poly_pseudo_mod, as a result of which I was
just using fmpz_poly_pseudo_divrem. I think Sage currently
That certainly looks like an error message FLINT would output.
One possibility is that the problem occurs only on 32 bit machines or
only 64 bit machines and not the other kind. Have you got access to
both 32 and 64 bit architectures to try this on?
Does this code just literally call
Dear Bill,
Thank you for looking at this thread!
On Jan 29, 12:54 am, Bill Hart goodwillh...@googlemail.com wrote:
That certainly looks like an error message FLINT would output.
One possibility is that the problem occurs only on 32 bit machines or
only 64 bit machines and not the other kind.
On Jan 29, 12:54 am, Bill Hart goodwillh...@googlemail.com wrote:
One possibility is that the problem occurs only on 32 bit machines or
only 64 bit machines and not the other kind. Have you got access to
both 32 and 64 bit architectures to try this on?
Running the commands on a similar set up
11 matches
Mail list logo