You are quite right, probably a wrong hypothesis on my part, albeit looking at the values in the data sample supplied in the OP, many come pretty close to the 32-bit signed integer limit, leading to think that the others might just be above it. Actually, thinking again about it, it seems to me that Perl itself (and, I guess pure Perl modules) can handle larger integers (or possibly I am lucky enough to use only 64-bits integers on the platforms I have been using in the recent years). But I have encountered the problem in the past with some modules and I am almost sure that I have also encountered the NaN thing with integers with some of them. It is too long ago for me to remember the details, though, I may confuse different issues. Anyway, we don't know enough about the OP's program to make this type of hypotheses.
| [reply] |
I am almost sure that I have also encountered the NaN thing with integers with some of them
That cannot be. NaN is a purely floating point concept.
It is the meaning ascribed to a set of bit patterns within the range of the 2**32 (float) or 2**64 (double) possible patterns that do not have a logical meaning when interpreted as floats or double respectively.
All the 2**32 bit patterns for 32-bit ints and all 2**64 bit patterns for 64-bit ints have a defined meaning. (Actually some of them have two defined meanings; one each for signed and unsigned.)
The point being, there is simply no purpose or scope for any integer bit-pattern to be defined as Not a Number.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
NaN is a purely floating point concept
It occurs to me that there is indeed a way (in perl) to generate a NaN using only integer values:
C:\>perl -le "$x = (2**1025) / (2**1025);print $x;"
-1.#IND
(For those unfamiliar with MS Windows notation, -1.#IND is one of the ways that it represents a NaN)
This, of course, doesn't contradict anything you've said. And it would take some clever legalese to show that this example proves that NaN *can* result from integer overflow ;-)
But it might count as a "trick" method of generating a NaN in perl using only integer values.
NOTE: If your perl's NV is a long double, then 1025 probably won't be a large enough power to generate the NaN.
Cheers, Rob | [reply] [d/l] |