Mathieu Bouchard wrote:
On Sun, 5 Dec 2004, Lex Ein wrote:
At first glance, Microsoft C and GNU both provide quite adequate double and long double mantissa size, so the existence of this data degradation is odd.
Pd Floats are 32-bit, or 1:8:23-bit to be exact. So you can't have more than 24 significant bits, and so (1<<24)+1 = 16777217 is the first integer not representable as a float (it gets rounded).
Pd is currently pretty much stuck to float32, Miller having refused the int/float separation and any kind of number type distinction; there is no provision for anything other than float32.
So if you want more precision you will have to cut down your data into smaller pieces, or use something else than Pd for handling those values that need more precision. Some of the scripting languages connectable to Pd support float64 and/or illimited-precision integers (both Ruby and Scheme have those two types; Python must have something similar too)
I agree with Lex that float64 aka double would be a better choice than float32, since all current hardware has 64-bit fpus anyway, it would hardly present a performance penalty, besides the obvious increase in memory usage.
Maybe you could just recompile Pd with a '#define float double' ?