Re^3: Odd error message

input '1.84467440869813e+019' must be a positive integer

A rather odd message, given that '1.84467440869813e+019' is a positive integer value.
I think next_prime() must be looking for an IV or UV, but the value about which it complains is too large to fit into an IV/UV and has been converted to an NV (double precision float).

I can't quite reconcile the error message you've provided with the Math::Prime::Util (version 0.53) source.
Perhaps I was looking in the wrong place, or perhaps I was looking at the wrong version.
If you're not already using 0.53, consider upgrading to it - it might accept such values (dunno).

Also note that, although your script loads the Math::BigFloat module, I can't see any Math::BigFloats being used anywhere in your code.
And I don't think next_prime() would accept a Math::BigFloat input, anyway - though I haven't tested.

Cheers,
Rob

Comment on Re^3: Odd error message

Replies are listed 'Best First'.
Re^4: Odd error message by danaj (Friar) on Sep 15, 2015 at 21:30 UTC
The issue is that the module got an NV, not a UV, IV, or numerical string. Sure, it can convert it, but it will probably not be what the caller intended. The source for almost all functions call _validate_int() on inputs, which is where the error message occurs. Edit: The value it dies on for me has exceeded 64 bits, so there is no way the module would get the intended input. Better to die than give a wrong answer. In theory to work with larger inputs, we should be doing the input calcs as BigInt (or Math::GMP or Math::GMPz, etc.) to make sure they're correct and scale past 64-bit, then do the gap/log($num) making sure the inputs are BigFloat. The reason we wouldn't want to let $num be an NV for the log calc is that these scripts should scale to $num values of 20k+ digits, which won't fit in a double or long double.	[reply]

Replies are listed 'Best First'.

Re^4: Odd error message
by danaj (Friar) on Sep 15, 2015 at 21:30 UTC

The issue is that the module got an NV, not a UV, IV, or numerical string. Sure, it can convert it, but it will probably not be what the caller intended. The source for almost all functions call _validate_int() on inputs, which is where the error message occurs.

Edit: The value it dies on for me has exceeded 64 bits, so there is no way the module would get the intended input. Better to die than give a wrong answer.

In theory to work with larger inputs, we should be doing the input calcs as BigInt (or Math::GMP or Math::GMPz, etc.) to make sure they're correct and scale past 64-bit, then do the gap/log($num) making sure the inputs are BigFloat.

The reason we wouldn't want to let $num be an NV for the log calc is that these scripts should scale to $num values of 20k+ digits, which won't fit in a double or long double.

[reply]