> On Thursday, April 26, 2018, 4:30:47 AM EDT, hans w. koch > <hansw.k...@gmail.com> wrote: > thanks orm and cyrille
> for forcing me to acknowledge, that i´ve indeed hit the IEEE ceiling here. > i stubbornly tried to turn a blind eye to that... > i am using pd 48-1 in 64bit but to my understanding internally it stil > computes single precision. and the copy of pd-double floating around, doesn´t provide the lovely amenities of the text objects, on which most of my operations rely. There is a student working on double-precision t_float in Purr Data as part of GSoC this summer. -Jonathan > maybe its finally time to look into python… > all best hans > Am 26.04.2018 um 10:13 schrieb Orm Finnendahl > <orm.finnend...@selma.hfmdk-frankfurt.de>: > > Hi Hans, > > this is related to the integer precision of float numbers. In 32-bit > pd to my knowledge single-floats as specified here are used: > > https://en.wikipedia.org/wiki/IEEE_754 > > To be able to use bigger integers you can cascade more than one number > (like hours/minutes/seconds in a clock), if you want to calculate aith > these, implement abstractions for the needed mathematical functions, > using e.g. list representations of the individual numbers as in/output. > > Unfortunately this is also related to indexing into arrays limiting > the maximum address. > > Another solution could be to use 64-bit pd with double float > resolution. > > -- > Orm > > > Am Donnerstag, den 26. April 2018 um 09:57:35 Uhr (+0200) schrieb hans w. > koch: >> thanks, cyrille, >> >> but why does the computation for 5pow12 [print start] in my patch then still >> produce 2.44141e+08? >> or 5pow12 - 4pow12 work? >> (see attached) >> >> cheers hans >> > > >> >>> Am 26.04.2018 um 09:46 schrieb cyrille henry <c...@chnry.net>: >>> >>> hello, >>> >>> this is not a probem with until, but a problem of big number precision. >>> see attachment. >>> cheers >>> c >>> >>> >>> Le 26/04/2018 à 09:30, hans w. koch a écrit : >>>> dear miller, >>>> all >>>> for a project i am working with very high number of iterations. >>>> but it seems i´ve literally hit a ceiling with [until] >>>> for 4pow12 iterations it performs fine. >>>> but 5pow12 doesn´t. >>>> feeding it into a counter, 5pow12 produces the same result as 4pow12. >>>> attached a small patch to demonstrate. >>>> is this limitation by purpose? >>>> (i have a workaround not using [until], but wanted to make sure i didn´t >>>> overlook something) >>>> thanks >>>> hans >>>> _______________________________________________ >>>> Pd-list@lists.iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> https://lists.puredata.info/listinfo/pd-list >>> <big_number_precision.pd>_______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >> > >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
