I think Pd uses %g which probably means %.6g by default, but it looks more like %.5g.
You're right, the precision is only lost when the patcher is written out somewhere.
In the attached patcher clicking on [1( calculates pi, which gets printed to a number box and the screen in 5 digit precision as 3.14159, but the subsequent [sin] object gives a value much closer to zero than when you click on [3.14159(, so the numbber box is hiding some extra precision.
Martin
But whatever the theoretical precision of a float, I think the thing that makes Pd floats less precise than Max floats lies in the use of the %g format specifier to print them out, which can result in a lower precision than the float is capable of.
The %g specifier is able to print at full precision, if you instruct it to, but pd only uses something like %.6g, whereas you'd need %.8g to conserve all the binary precision (%.7g is slightly not enough, %.8g is too much, but there's not a %.7½g).
To conserve the decimal precision, however, you flip it around : in a 32-bit float, you can only load a %.7g without loss, and a %.8g won't fit. But this only applies if the data really has %.8g precision to start with, which is not the case with %.8g numbers that came from float32, which really have only 7.2247 decimals of precision, which fits exactly in float32.
This makes it possible to use maximum precision float calculations inside of objects but not between them.
Between two objects communicating by float messages from outlet to inlet, things happen only in binary, and you already know that. This means that you can have 24-bit float32 precision between objects. The drop to 19.93 bits of precision (%.6g) occurs only when converting to decimal ascii text and back.
Right ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list