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

Quoting Jonghyun Kim <agitato816@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

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list