Thanks for the solution. I can understand the actual problem on 32bit. But I think still this is a bug.|
| +------+
[f] |
| |
[+ 1] |
| |
[% 6] |
| |
[t f f] |
| +--+
|Could you give me the patch again with easily drawing? Sorry I can't recognize your patch drawing...Many thanks,akntkOn Mon, Oct 6, 2014 at 1:22 AM, <zmoelnig@iem.at> wrote:(had to find a real compuer before anwering the actual question)this very much sounds like a problem with floating point precision overrun.
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)
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