Re: [PD] [until] ceiling
2018-04-26 11:23 GMT-03:00 Jonathan Wilkes via Pd-list : > > > There is a student working on double-precision t_float in Purr Data as > part of GSoC this summer. > wasn't there a talk here on the pd list about double precision too? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
> On Thursday, April 26, 2018, 4:30:47 AM EDT, hans w. koch > 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 > : > > 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 : >>> >>> 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 >>> ___ >>> 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
Re: [PD] [until] ceiling
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. maybe its finally time to look into python… all best hans > Am 26.04.2018 um 10:13 schrieb Orm Finnendahl > : > > 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 : >>> >>> 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 >>> ___ >>> 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
Re: [PD] [until] ceiling
well, 5^12 is in the range of the value represented by a float number. but at this value, the precision is more than 1, so it's can be computed directlly, but not with single iteration. I guess wikipedia will explain it in more detail than what I can do in a mail. https://en.wikipedia.org/wiki/Floating-point_arithmetic more specifically : https://en.wikipedia.org/wiki/Floating-point_arithmetic#Range_of_floating-point_numbers https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems cheers c Le 26/04/2018 à 09:57, hans w. koch a écrit : 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 : 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 ___ 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
Re: [PD] [until] ceiling
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 big_number_precision2.pd Description: Binary data > Am 26.04.2018 um 09:46 schrieb cyrille henry : > > 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 > ___ > 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
Re: [PD] [until] ceiling
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 #N canvas 254 106 608 443 10; #X obj 145 181 pow; #X msg 164 159 12; #X obj 145 132 t f b f; #X obj 144 215 t b f b f; #X obj 161 245 until; #X obj 144 308 f; #X obj 144 336 print end; #X msg 206 245 0; #X obj 161 274 f 0; #X obj 186 274 + 1; #X obj 238 244 print start; #X msg 144 61 4; #X msg 224 94 5; #X text 54 40 4pow12 produces same result for start + end; #X text 198 75 5pow12 doesn´t=same result as 4pow12; #X obj 462 229 pow; #X msg 481 207 12; #X msg 455 183 4; #X obj 461 256 t f f; #X obj 459 291 + 1; #X floatatom 527 297 9 0 0 0 - - -, f 9; #X floatatom 509 327 9 0 0 0 - - -, f 9; #X obj 462 146 t b b; #X obj 466 120 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 461 326 ==; #X obj 457 369 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X connect 0 0 3 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 2 1 1 0; #X connect 3 0 5 0; #X connect 3 1 4 0; #X connect 3 2 7 0; #X connect 3 3 10 0; #X connect 4 0 8 0; #X connect 5 0 6 0; #X connect 7 0 8 1; #X connect 8 0 9 0; #X connect 8 0 5 1; #X connect 9 0 8 1; #X connect 11 0 2 0; #X connect 12 0 2 0; #X connect 15 0 18 0; #X connect 16 0 15 1; #X connect 17 0 15 0; #X connect 18 0 19 0; #X connect 18 1 20 0; #X connect 18 1 24 1; #X connect 19 0 21 0; #X connect 19 0 24 0; #X connect 22 0 17 0; #X connect 22 1 16 0; #X connect 23 0 22 0; #X connect 24 0 25 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [until] ceiling
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 until_ceiling_test.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list