> more that 7 digit but less than 8 digits ... > so, 4/3 =! 1.33333 > but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8? In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits... I have a work around using expr. Just put the number in parenthesis. Try [expr 4./3 == (1.33333333)] (8 "3") but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3" cheers 2015-01-29 14:58 GMT-02:00 Cyrille Henry <[email protected]>: > hello, > > ok, claude was faster to answer, but since i already write my mail, i send > it anyway... > > > pd internal resolution is float32. > (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but > less than 8 digits) > pd graphical representation is 6 digits > > so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") > even if both are represented with the same number of 3... > this is a generic problem of computer float. > > the only odd thing concerning pd is that number are also saved with 6 > digit. > (so precision can be lost when a patch is saved) > > try the attachment patch. > then save the patch, and open it back, and see that precision is lost. > (I have to modifies the patch as text file to have this behaviors, but you > can also have the save precision when creating an object... until you > save/load the patch) > > you can also have a look on the top right of the patch: a weird effect of > float precision... > > cheers > c > > Le 29/01/2015 17:17, Alexandre Torres Porres a écrit : > >> Well, thanks everyone. >> >> And now for some related issues. >> >> Pd can only represent up to 6 significant digits, so they say. For >> example, in a message, you can have a number with up to 5 decimal places, >> like: -5.29314e+12 >> >> but it does have a better internal resolution, if you compare 4 / 3 to >> 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check). >> >> So, what's this internal resolution? And why can't you have the same >> resolution in a message? >> >> thanks >> >> 2015-01-28 16:06 GMT-02:00 Martin Peach <[email protected] <mailto: >> [email protected]>>: >> >> On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : >> >> > it's a limitation of 32 bit float >> >> I thought so, but same happens when I use the new Pd Vanilla >> 64 bits... >> >> this mean that it's compiled for 64 bit CPU, not that float are >> store on 64 bits >> >> Also last time I checked, Pd saves floats by first printing them to 6 >> digit precision, so they have even less range than a 'float' type. >> You could use an object made with pdlua to manipulate large >> floating-point numbers, as there is no(?) limit to the size of a float in >> lua. >> >> Martin >> >> _______________________________________________ >> [email protected] <mailto:[email protected]> mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >> listinfo/pd-list >> >> >>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
