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.

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.

Are you sure that you are not encountering an endian problem? For example, the 4 byte value 0x7ff00000, decoded as a big-endian float produces a valid number:

print unpack 'f>', pack 'V', 0x7ff00000;;
8.6273742553086e-041
[download]

But treated as a little-endian value it produces NaN:

print unpack 'f<', pack 'V', 0x7ff00000;;
1.#QNAN
[download]

Just a thought.