[PD-dev] [ pure-data-Bugs-1996275 ] floats show as 6 digits, but implemented at higher precision

SourceForge.net noreply at sourceforge.net
Fri Jul 25 16:09:20 CEST 2008


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&group_id=55736

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_language

//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-25 10:09

Message:
Logged In: YES 
user_id=27104
Originator: YES

I updated float-precision-misrepresentation.pd to make it clear that the
width of the object box is not causing the rounding.
File Added: float-precision-misrepresentation.pd

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-25 10:07

Message:
Logged In: YES 
user_id=27104
Originator: YES

So this doesn't just happen on saving, but also on loading.  I attached
long_floats.pd which I edited with emacs to have 9 digit floats.  They get
rounded to 6 digits upon load.

Also, just typing a number with more than 6 digits into an object box
rounds it once the object is created.  So my guess is that this problem is
caused by conversion to binbufs rather than saving the file as was
previously mentioned.
File Added: long_floats.pd

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-24 23:37

Message:
Logged In: YES 
user_id=27104
Originator: YES

"floats show as 6 digits, but implemented at higher precision" outlines
the inconsistency, which is the bug in question.  Feel free to rewrite the
title if you think you can make a clearer description.  (But please don't
do it out of spite, like switching the bug to Invalid.)

This is the key to this problem:

[float 0.100000001490116119384765625] gets rounded to 6 digits.  I don't
know the exact source of the problem.  If you do, please tell us. 

----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-24 11:21

Message:
Logged In: YES 
user_id=564396
Originator: NO

my patch 10percent.pd illustrated exactly the problem you initially
reported and which is still described in the summary line.


i don't know what bug you want to report exactly, but what you say in the
subject ("floats show as 6 digits, but implemented at higher precision") is
imho invalid as a bug-report (and thus a waste of time; we agree here). so
i closed it (but of course i will now leave it open)

if you want a binary patch-format with full precision, you should file a
feature request (preferrably a new one).

if you think that the text patch-format should is buggy as it discards
precision, you should say so in the bug-report.

your analogy to C's printf is invalid insofar, as you can do the same with
Pd, either as shown in my 10percent.pd patch or by using [makefilename]'s
formatting.




----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-24 11:05

Message:
Logged In: YES 
user_id=27104
Originator: YES

Why would you close the bug if you agree that there is a problem?  "The
only valid issue i can see is, that precision gets lost when saving and
re-loading a patch".  As for the 10percent.pd patch, that is just wasting
our time, since that is demonstrating the manual control of display
precision, not the bug that we are talking about.

No other programming language that I use has this problem.  With C, you
have the power to control the precision that is displayed with printf(),
for example.  And if you set a variable in C, the editor doesn't
automatically round it off to 6 digits when you save it.

float myNumber = 0.100000001490116119384765625;

versus:

[float 0.100000001490116119384765625]


----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-24 04:26

Message:
Logged In: YES 
user_id=564396
Originator: NO

imho, this bug-report "floats show as 6 digits, but implemented at higher
precision" is invalid.

first of all, i don't see how loat-precision-misrepresentation.pd is any
more helpful than my patch.
it only illustrates that Pd is working correctly (0.999999+9e-7 is
0.9999999 which IS smaller than 1 and therefore correctly outputs the value
to the left outlet of [moses]).
the rest is just a matter of representation (see attached 10percent.pd
patch)
you are surely aware that "all that is gold does not glitter" and a visual
representation is not necessary the thing per se.


showing a 32bit floating point value is always problematic: either you
sacrifice precision (in the display!) or you sacrifice readability.
this get's worse by the fact that floating point numbers do a bad job in
representing numbers whose nominators are not power-of-2.
e.g. "0.1" really cannot be expressed with a floating point number; the
closest you can get is about "0.100000001490116119384765625".

this is the reason why Pd does not try to display the _exact_ value of a
number but rather accepts a little rounding:
i guess you would file a bug-report if the result of 1/10 would show up as
"0.100000001490116119384765625"
see
http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding
for more information on this dilemma.


a less sophisticated way would be to display the floating-point numbers as
4byte binaries (display "0x3DCCCCCD" instead of "0.1")
it needs some time to get used to it, but once you are there...

another way to make Pd represent all numbers exactly, is to limit Pd's
valid numbers, e.g. to just integers.


the only valid issue i can see is, that precision gets lost when saving
and re-loading a patch; the obvious fix for this is to use a binary
format.
you could file a feature-request for such a thing if you really need it.


File Added: 10percent.pd

----------------------------------------------------------------------

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&group_id=55736




More information about the Pd-dev mailing list