Le 29/01/2015 18:36, Alexandre Torres Porres a écrit :
> 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?
yes
about 7.22 as Claude pointed : log(2^24-1)
2^24-1 is the max value coded in 23bit,
log(x) compute the number of digit of a number.
unfortunately, the result is not an integer.
How does that work? In practice, is it 7 or 8?
in practice, number are rounded to the closest value that can be represented in
this format.
forget about the comma :
the max number that can be represented without exponent is 2^24-1 (max value of
23bits)
i.e 16777215
in this case, 8 correct digits
if you add 1, it should be 16777216, but that need 24 bit, and it's not
possible in a float.
so it's noted 1677722 * 10^1
...
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal
digits...
better to say a 9 digit number.
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"
7 "3", mean 8 digits number: max precision of a float-> no surprise.
cheers
c
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry <[email protected]
<mailto:[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]> <mailto:[email protected]
<mailto:[email protected]>>__>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <[email protected]
<mailto:[email protected]> <mailto:[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]> <mailto:[email protected]
<mailto:[email protected]>> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/__listinfo/pd-list
<http://lists.puredata.info/listinfo/pd-list>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
