[PD] strange bug [f], Pd 0.45.5

[zmoelnig at iem.at]

(had to find a real compuer before anwering the actual question)

Quoting Jonghyun Kim <agitato816 at gmail.com>:
> Pd 0.45.5 (Vanilla)
> Mac OS X Mavericks 10.9.5
>
>
> I don't really know why this bug cause, or only my problem. This bug
> sometimes appears. I think this is very critical bug.
> [f] storing bug
>
> [metro 1]
> |
> [f 0]
> |  /
> [+ 1]
> |
> [% 6]
>
> respected result: 0, 1, 2, 3, 4, 5 (repeat)
>
> bug: 4, 4, 4, 4, 4 (always 4)


this very much sounds like a problem with floating point precision overrun.
an [f] object (and actually *any* number within the Pd universe) will  
hold a single precision 32bit floating point number, which can only  
represent *consecutive* integer values up to 16777216.
(consecutive means, that [f] can hold representations of both (e.g.)  
1000023 and 1000024).
if the numbers go higher, singple precision floats will have gaps  
bigger than 1.0 inbetween them (e.g. the next number after 16777216  
representable by [f] is 16777218) - this breaks a counter that  
increments 1 (since  16777216+1 will be evaulated to ~16777216!)

the solution is actually quite simple: never allow your number to grow  
as big as that.

in your counter this means, that the feeback part, must include the [%  
6] (so the numbers in the counter will only ever stay in the range  
0..6):

|
| +------+
[f]      |
|        |
[+ 1]    |
|        |
[% 6]    |
|        |
[t f f]  |
|     +--+
|

btw, you ASCII rendering of the patch did not use [trigger]. you  
should always use it when you want to connect multiple inlets to a  
single outlet.

mfgsdr
IOhannes