> On Thursday, April 26, 2018, 4:30:47 AM EDT, hans w. koch <hansw.koch@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.finnendahl@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 <ch@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