Bugs item #1996275, was opened at 2008-06-17 12:38 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody)
Summary: floats show as 6 digits, but implemented at higher precision
Initial Comment: Sometimes some duplicates get through [change] since it is doing a != for the comparison. Instead it should do a comparison with a set precision, something like this:
http://howto.wikia.com/wiki/Howto_compare_float_numbers_in_the_C_programming...
//compares if the float f1 is equal with f2 and returns 1 if true and 0 if false int compare_float(float f1, float f2) { float precision = 0.00001; if (((f1 - precision) < f2) && ((f1 + precision) > f2)) { return 1; } else { return 0; } }
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-23 16:56
Message: Logged In: YES user_id=27104 Originator: YES
This is a more fundamental bug then. It is not just [print] that is limited to 6 digits. You can't represent more than six digits in anything that gets saved. Yet things in the C implementation are working at higher precision. That's a pretty serious disconnect between what's happening in the implementation and how it is represented in Pd.
For example, anytime you have you any number with more than 6 digits in an object or message box, and you save the patch, it'll be automatically rounded to 6 digits. Also, consider the attached patch, it shows that using [moses] can be similarly misrepresented. I don't think that the pd_precision.pd patch represents this issue very well.
Yes, this is a known issue, but this is just another illustration of where it's a problem. I have forgotten what is the source of this disconnect. File Added: float-precision-misrepresentation.pd
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 10:33
Message: Logged In: YES user_id=564396 Originator: NO
attached is a patch that simulates what you experienced.
btw, it is rather simple to quantize your numbers with an abstraction, if you don't need full precision.
also it might be a nice feature to [change] to allow a certain fuzziness. i guess you could submit a feature-request for this instead of this bug-report. File Added: pd_precision.pd
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 10:23
Message: Logged In: YES user_id=564396 Originator: NO
ah i see, but this is a misunderstanding on your side.
Pd uses _full_ precision of floats. however it will only display (and save) a number with a limited precision. i don't think we should change [change] just because [print] is unable to show enough precision.
if you use [tgl] instead of [print] you will notice that even more values look the same :-)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-07-23 10:08
Message: Logged In: YES user_id=27104 Originator: YES
Since this comparison is happening in C space, it is done using the full precision of the float. But Pd only uses 6 digits of precision, so the comparison should match that, not what is happening in C space.
Basically, I hooked up a [change]-[print] to some sensor data, and it was quite common to see the exact same number printed out one after the other.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-07-23 03:26
Message: Logged In: YES user_id=564396 Originator: NO
do you have a practical example that exposes the bug?
in theory you are of course right, but in practice i wonder how this can be applied to [change].
e.g. if i send "1" and the result of "2/2" to change, i might consider these two as different enough :-)
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275...