No floating points have been involved in the code. The error should be
caused by divide-by-zero.
If N>46341, a product of two integers might be overflow and result in a
negative number. Consequently, the range of a denominator would start from
a negative integer and end at a positive number, and t
I'm curious whence the "RuntimeError: Floating point exception,"
perhaps I should just go look at the code...
On Tue, Mar 5, 2013 at 5:02 PM, William Stein wrote:
> On Tue, Mar 5, 2013 at 10:55 AM, Robert Bradshaw
> wrote:
>> On Tue, Mar 5, 2013 at 7:39 AM, David Loeffler
>> wrote:
>>> On 5 Mar
On Tue, Mar 5, 2013 at 10:55 AM, Robert Bradshaw
wrote:
> On Tue, Mar 5, 2013 at 7:39 AM, David Loeffler
> wrote:
>> On 5 March 2013 06:54, Peng Tian wrote:
>>> Dear David,
>>> You are right. I tried to change the data type of the code in sage, which is
>>> "int" type in the source code of SAGE
On Tue, Mar 5, 2013 at 7:39 AM, David Loeffler
wrote:
> On 5 March 2013 06:54, Peng Tian wrote:
>> Dear David,
>> You are right. I tried to change the data type of the code in sage, which is
>> "int" type in the source code of SAGE and now I'm using "long int" instead.
>> The previous error is go
On 5 March 2013 06:54, Peng Tian wrote:
> Dear David,
> You are right. I tried to change the data type of the code in sage, which is
> "int" type in the source code of SAGE and now I'm using "long int" instead.
> The previous error is gone and everything is working well now.
>
> Thanks a lot!
>
>
That sounds quite reasonable. I try to read the code again and search a
solution. Thank you very much.
On Thursday, February 28, 2013 2:05:07 PM UTC+1, David Loeffler wrote:
>
> The bug also occurs on Sage 5.7, and a quick-and-dirty bisection
> script shows that n = 46341 does work and n = 463
I've asked him in fact, but he is currently not working on it.
Bosman's code certainly performs well on the case which has been done by
him. This error occurs only on my computation, which seems too cumbersome
as far as it goes.
Anyway, thanks for all your advice.
On Wednesday, February 27,
The bug also occurs on Sage 5.7, and a quick-and-dirty bisection
script shows that n = 46341 does work and n = 46342 does not. Since
46341 is almost exactly the square root of 2^{31}, and the relevant
bits of code seem to use C int variables rather than Sage integers
(presumably for speed reasons),
Try asking Bosman directly; I don't know if he reads this list.
John
On 27 February 2013 15:23, Peng wrote:
> Dear John Cremona,
> Thanks for your reply.
>
> For n=45000 or smaller, it works well and gives an output. Then the next
> number I tried is 5 and this gave an Error.
>
> In sage 5.
Dear John Cremona,
Thanks for your reply.
For n=45000 or smaller, it works well and gives an output. Then the next
number I tried is 5 and this gave an Error.
In sage 5.7, this doesn't work neither.
I even don't know yet why this happens exactly.
PS:
I'm trying to compute the modular Galo
I cannot think of a reason for computing Heilbronn matrices of such
large index, so you have one? And how does it perform for smaller n,
say 1000, 1, 2, ...?
Lastly, Sage-5.7 has been released so you should upgrade (but I am not
saying if any relevant code has changed between 5.4.1 and 5.
Dear all,
I've tried to compute Heilbronn Matrices for n=5 in sage 5.4.1, but the
following Error comes out when I run
* sage: H=HeilbronnMerel(5)*
*RuntimeError Traceback (most recent call last)*
*/home/guest
12 matches
Mail list logo
