[PD] "wrong" floating point values in pyext

[day 5]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>