On 05. Oktober 2014 20:40:19 MESZ, Jonghyun Kim <agitato...@gmail.com> wrote: >Thanks for the solution. I can understand the actual problem on 32bit.
You might be confusing things here: Currently pd will always uses single precision floats (which happen to have 32bit on all known platforms), even when run "on" a 64bit system. >But >I think still this is a bug. Yes, in your patch :-) the question is, whether pd should work around system limitations. Eg if you ask it for a tabke with 10 tera-samples and you only have 4gb ram, should it... > >| >> | +------+ >> [f] | >> | | >> [+ 1] | >> | | >> [% 6] | >> | | >> [t f f] | >> | +--+ >> | > > >Could you give me the patch again with easily drawing? Sorry I can't >recognize your patch drawing... check it with a monospaced font. (and no, i cannot redraw it on my smartphone). > >Many thanks, >akntk > >On Mon, Oct 6, 2014 at 1:22 AM, <zmoel...@iem.at> wrote: > >> (had to find a real compuer before anwering the actual question) >> >> >> Quoting Jonghyun Kim <agitato...@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 >> > > >------------------------------------------------------------------------ > >_______________________________________________ >Pd-list@lists.iem.at mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list mfg.ugd.fhj IOhannes -- Sent from my pdp-11 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
