Hello list !
I've noticed an unusual behavior of "select" object on my computer: see "para.pd" for details.
This object doesn't recognize some numbers (though they are set in its argument...) and pass them through its right outlet.
For example, when counting regularly every 0.01 and routing the sum numbers through "sel" object, it passes number 0.05 out the right outlet (though its argument is set to 0.05) as if coming numbers were not themselves...
Could anyone tell me what am i doing wrong ..
On Fri, 5 Mar 2004, [koi8-r] "Yury[koi8-r] " wrote:
I've noticed an unusual behavior of "select" object on my computer: see "para.pd" for details. This object doesn't recognize some numbers (though they are set in its argument...) and pass them through its right outlet.
For example, when counting regularly every 0.01 and routing the sum numbers through "sel" object, it passes number 0.05 out the right outlet (though its argument is set to 0.05) as if coming numbers were not themselves...
Could anyone tell me what am i doing wrong ..
Only fractions with power-of-two denominators (2, 4, 8, 16, ...) are actual float values. The others only get approximated. 0.05's closest approximation is:
0.0500000007450580596923828125
which is also
13421773 / 2^28
However sometimes the value gets rounded otherwise, so there's really a big problem with using [==], [select], and the like, on number that can be imprecise.
Instead of [== 0.05] you would have to do something like:
[- 0.05] | [abs] | [< 0.000001]
Or something like that. Note that the error margin you can expect may vary alot depending on what computations you are performing, and how big the number is. Note that Pd's floats are 32=23+8+1 bits, so you get an error of about 2^-23 times the value itself, plus computational error.
Mathieu Bouchard http://artengine.ca/matju