Hi,
I admit, I'm currently still using py/pyext 0.2.1pre, if the following is fixed in later versions, please ignore...
This is code for a simple pyext class which stores a float:
import pyext class Anyarg(pyext._class): _inlets = 1 _outlets = 1 def __init__(self): self.x = 0.0 def x_1(self,n): self.x = n print self.x
However if I set this float x to a floating point value like "0.02", Pd will print a value that is only near the target value:
"x 0.2" results in a printout of 0.20000000298
Is there something wrong?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
However if I set this float x to a floating point value like "0.02", Pd will print a value that is only near the target value:
"x 0.2" results in a printout of 0.20000000298
Is there something wrong?
IEEE 754 floating point numbers aren't able to encode 0.2 ... pd's print is rounding to 6 digits, python doesn't round, though ...
see http://en.wikipedia.org/wiki/IEEE_floating-point_standard for details ...
tim
On Mon, 20 Feb 2006, Tim Blechmann wrote:
IEEE 754 floating point numbers aren't able to encode 0.2 ... pd's print is rounding to 6 digits, python doesn't round, though ...
Python rounds too, but computes with 64-bit floats, just like Ruby. You see that Python only printed 11 significant digits, but with 64-bit floats you can have as many as 15, so there's rounding going on here.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 20 Feb 2006, Frank Barknecht wrote:
However if I set this float x to a floating point value like "0.02", Pd will print a value that is only near the target value:
"x 0.2" results in a printout of 0.20000000298
Is there something wrong?
floating point is not very good at representing some numbers, it can only do it approximately, this is also troublesome if you want to build a counter that counts by 0.01 increments and stops if the sum == 100 This will not work, because it never sums up to 100.
Guenter
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hay guyes what's goin on in this thraed lol ?
#N canvas 480 195 240 203 10; #X obj 23 119 / 100; #X obj 24 145 prepend set; #X obj 23 93 counter 10000; #X msg 24 172 26.36; #X obj 66 118 sel 100; #X obj 123 118 s $0-turnoff; #X obj 23 7 r $0-turnoff; #X obj 68 52 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10 -262144 -1 -1 2 256; #X obj 21 30 cnv 15 147 17 empty empty empty 20 12 0 14 -245368 -66577 0; #X obj 23 71 metro 2; #X obj 23 30 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X text 47 30 << click to start; #X connect 0 0 1 0; #X connect 0 0 4 0; #X connect 1 0 3 0; #X connect 2 0 0 0; #X connect 4 0 5 0; #X connect 6 0 10 0; #X connect 7 0 9 1; #X connect 9 0 2 0; #X connect 10 0 9 0;
./d5
On Feb 20, 2006, at 6:00 AM, geiger wrote:
floating point is not very good at representing some numbers, it can only do it approximately, this is also troublesome if you want to build a counter that counts by 0.01 increments and stops if the sum == 100 This will not work, because it never sums up to 100.
Guenter
On Mon, 20 Feb 2006, Frank Barknecht wrote:
Hallo, day 5 hat gesagt: // day 5 wrote:
hay guyes what's goin on in this thraed lol ?
You're cheating. Try attached variation!
Yes, thats what I meant. I have seen this "mistake" happen several times, the bad thing is that I think it is not easy to handle it from within Pd, as the error depends on the numbers you sum up, so you can't change select to react on a range instead of a specific number. It is said to be bad to test for equality with floating point numbers, and here is why. The best thing is to design your counters the way day5 does it, but it is something you have to know, otherwise you really get bad surprises.
Günter
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, geiger hat gesagt: // geiger wrote:
Yes, thats what I meant. I have seen this "mistake" happen several times, the bad thing is that I think it is not easy to handle it from within Pd, as the error depends on the numbers you sum up, so you can't change select to react on a range instead of a specific number. It is said to be bad to test for equality with floating point numbers, and here is why. The best thing is to design your counters the way day5 does it, but it is something you have to know, otherwise you really get bad surprises.
I think, [select] should be avoided generally to end a counter. It carries too many assumptions about the counter value, that could turn out false. What if I [select]-wait for 16, and then later add a [mod 16] inside? 16 will never be reached. What if I count only even numbers and try to end the counter with 99? 99 will never bit hit. Etc. usw.
In C or similar programming languages, you never see loops made like this:
for (i=0, i != 99, i++) ...
Instead real loops walk this way:
for (i=0, i < 100, i++) ...
Using [select] in a counter is an accident waiting to happen. Unfortunatly it is taught in 2.control.examples/06.more.counters.pd :(
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Thanks Frank for showing a technique that uses [moses] instead!
I can see why this is the preferred behaviour, especially given your clear example.
./d5
On Feb 20, 2006, at 12:01 PM, Frank Barknecht wrote:
Hallo, geiger hat gesagt: // geiger wrote:
Yes, thats what I meant. I have seen this "mistake" happen several times, the bad thing is that I think it is not easy to handle it from within Pd, as the error depends on the numbers you sum up, so you can't change select to react on a range instead of a specific number. It is said to be bad to test for equality with floating point numbers, and here is why. The best thing is to design your counters the way day5 does it, but it is something you have to know, otherwise you really get bad surprises.
I think, [select] should be avoided generally to end a counter. It carries too many assumptions about the counter value, that could turn out false. What if I [select]-wait for 16, and then later add a [mod 16] inside? 16 will never be reached. What if I count only even numbers and try to end the counter with 99? 99 will never bit hit. Etc. usw.
In C or similar programming languages, you never see loops made like this:
for (i=0, i != 99, i++) ...
Instead real loops walk this way:
for (i=0, i < 100, i++) ...
Using [select] in a counter is an accident waiting to happen. Unfortunatly it is taught in 2.control.examples/06.more.counters.pd :(
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
day 5 -
Frank Barknecht -
geiger -
Mathieu Bouchard -
Tim Blechmann