Large and long numbers in Pd
How Pure Data treats large numbers and what trouble you might run into.
Large and long numbers are always interesting on computer systems, which are limited in the precision of the numbers which they can express. Pure Data is no exception in this respect. Here is some notes on the range and accuracy of floating point numbers in Pd:
According to IOhannes m zmoelnig, Pd uses double precision floating points (64 bits) internally and single precision (32 bits) externally. On my system, the highest number which I can find in Pd, which it does not simply consider 'infinite' is 3.40282e+38. This corresponds well to the maximum number in single precision floating points according to Wikipedia.
However, a different problem is likely to bite you much earlier: The Pd editor (at least the one in Pd vanilla) truncates any numbers to 6 digits, counting any digit before or after a comma (but not counting a suffix like e+12). For example, [f 1234567] is truncated to [f 1.23457e+06], [sel 1.000001] is truncated to [sel 1], and [route 123456e+12] is not truncated at all (but instead converted to the more convenient [route 1.23456e+17]). Numbers with more than 6 digits occuring in message boxes rather than object boxes behave slightly differently: they are not truncated immediately, but only when copy-pasted or duplicated, but also when a patch is closed and re-opened.
The interesting thing is that as long as the patch remains open, the right numbers are used in the background, so although [sel 1000000] and [sel 1000001] will both truncate to [sel 1e+06], the former will only route 1000000, and the latter only 1000001. Even more confusing as far as the latter case is concerned, the number 1000001 might even have come from a message box looking like [1e+06(, if you had created it by copy-pasting a [1000001( message box earlier. In other words, it is perfectly possible to have the following code appear twice in a Pd patch:
[1e+06( | [route 1e+06]
but behave totally different. Maybe none of the two actually routes 1000000, but the first one routes 1000001, and the second one 1000002.
However, Pd does keep its promise of "the print is the patch" eventually: as soon as the patch is closed and re-opened, all message boxes are truncated to 6 digits as well, and the truncated values are now applied for all object and message boxes, so any occurence of the above code would actually now route 1000000 (and now other number).
Obviously, this can result in frustration, and several people have run into the problem, for example when trying to get good resolution for GPS coordinates. A workaround is suggested here.