Skip Menu |

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 66732
Status: resolved
Priority: 0/
Queue: Math-BigInt

People
Owner: Nobody in particular
Requestors: peter.john.acklam [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.993
Fixed in: 1.997



Subject: Math::BigFloat->numify() returns Perl scalar string, not number
Contrary to the documentation, Math::BigFloat -> numify() returns a Perl scalar string, not a number. For instance, the following should print "1.23456e+105": $ perl -MMath::BigFloat -wle 'print Math::BigFloat -> new("123456e100") -> numify()' 123456e+100 And the following should overflow and print the appropriate representation of infinity: $ perl -MMath::BigFloat -wle 'print Math::BigFloat -> new("1e999999") -> numify()' 1e+999999 The bug is present at least all the way back to version 1.35.
The first case returns "1.23456e+105", which is, in fact, a number. Perl scalar numbers aren't going to be super-long digit strings. That would be a string. The second case returns "1.#INF", which appears to be a valid IEEE floating point string representation of positive infinity. This matches the result of: Show quoted text
>perl -MData::Float -wle "print Data::Float::pos_infinity"
1.#INF Please close this ticket.
On my Linux system, I get the bad "123456e+100" for all my perls with Math::BigFloat 1.993 or earlier. 1.997 and later return the proper 1.23456e+105. Similarly, 1.993 and previous gave the bad "1e+999999" for the second case, while 1.997 and later give "inf". Cygwin gives me similar behavior -- 1.993 gives bad results, 1.997 gives good. Strawberry Perl with Math::BigFloat 1.997 or 1.998 gives interesting behavior: the correct response for the first, but "1.#QNAN" for the second. It looks like somewhere between 1.993 and 1.997 the main issue got fixed. The only thing I see left is the NAN instead of INF response on Strawberry Perl.
... and it looks like the Strawberry Perl issue was a MS-DOS command line issue that was my fault, so it works just fine once with " and ' characters are worked out. 1.#INF returned as expected. This should be closed as fixed in 1.997.
Fixed