in reply to Re^2: NaN output
in thread NaN output

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.

Replies are listed 'Best First'.
Re^4: NaN output
by BrowserUk (Patriarch) on Mar 05, 2014 at 21:22 UTC
    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

      [download]
      (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]
        Yep, this is what I get on Cygwin: 
        $ perl -e '$x = (2**1025) / (2**1025);print $x;'
nan

        [download]
        But, of course, I am not claiming this to prove my original assumption in any way. We are talking here about manipulating numbers many many orders of magnitude larger, nothing to do with the usual integer overflow.
[reply]
[d/l]
        generate a NaN using only integer values ... 2**1025

        Whilst that construction uses 2 integer constants, the resultant value is not an integer.

        Similarly, this uses two integers in it construction, but the result is not an integer value: 1/7.

        I'll repeat it. "NaN is a floating point value and thus has nothing at all to do with numerical limits of integer data types."

        Like it, lump it, or obscure it. That remains true.

        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]
[d/l]
[select]

In Section Seekers of Perl Wisdom