On Mon, Apr 9, 2012 at 1:23 AM, Matteo Sisti Sette matteosistisette@gmail.com wrote:
On 04/08/2012 04:27 PM, katja wrote:
I've once compiled (vanilla) Pd with the format specifiers changed to print up to 8 significant digits, and soon found why it is normally done with 6 digits max. You get things like this:
33 * 0.3 = 9.900001
That is completely unrelated. That is an issue intrinsic in floating point numbers.
Reducing the precision of numbers when writing them to files (or when parsing messages or whatever) is an issue in Pd.
One thing is rounding numbers for _displaying_ them, another thing is rounding them when _storing_ them (whether in a file or wherever).
You're right. In Pd however, the format specifier %g is used for display (except for message boxes), and the same reformatted value is eventually saved to disk as text. Therefore, changing the format specifiers affect both representation and storage. The code is just simplistic on this aspect.
Doing it better would require a lot of modifications, more than changing some format specifiers. It's a pity we can't see MaxMsp's code, the issues seem to be neatly solved there, like:
- You can type, use and store very large floats if they are
representable, and if not representable, the nearest representable value is automatically displayed and stored.
- On the other hand, you can for example create [* 0.01] without it
being changed into [* 0.0999999] which would be the nearest representable value.
- The representation in a numbox reckons with the size of the numbox,
for example the result of 7.1 - 7 becomes 0.100 if the numbox can only hold 5 characters (while Pd gives 0.099 in that case).
It seems to me that they have had a thorough discussion on the matter, decided about what would be most useful in practice, and implemented it no matter how many conditional checks this would bring into the code.
Katja