in reply to Re: NaN output
in thread NaN output

You presumably get NaN (not a number) when you have an integer overflow on a 32-bit counter (i.e. a number larger than 2^31 - 1 = 2,147,483,647). Either you have a way to use 64 bbits counters or you may be you can use on of the modules for high prevision arithmetics such as BigInt.

NaN is a floating point value and thus has nothing at all to do with numerical limits of integer data types.


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.

Replies are listed 'Best First'.
Re^3: NaN output
by Laurent_R (Canon) on Mar 05, 2014 at 18:59 UTC
    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.
      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.
        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