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).
Consider this: I create a patch like this:
[9.900001(
|
[== 9.9]
|
[print]
This prints 0, as expected.
Then I save and close it. I load it, and it has been transformed into this:
[9.9(
|
[== 9.9]
|
[print]
which obviously prints 1.
This is WRONG, there's no reason why it could be good or even
acceptable. I do understand why it happens.
By the way, if you write into an object box:
[f 9.90001]
it is immediately changed into: [f 9.9]
Which is also WRONG (why shouldn't I be able to create an object with a
parameter value which _can_ be represented without loss of
information?), but it is much "less wrong" than the previous case in
that this is CONSISTENT. In this case, at least, "what you have is what
you save" (note that "what you see" is not an issue).
The case of message boxes (not to mention arrays) is devastating,
because you may not realise you're going to loose information until you
save the patch, close and reopen it.
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
