Re: [PD] [until] ceiling

2018-04-26 Thread Alexandre Torres Porres 
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

2018-04-26 Thread Jonathan Wilkes via Pd-list 
 > 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

2018-04-26 Thread cyrille henry 

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

2018-04-26 Thread 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



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

2018-04-26 Thread 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

#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

2018-04-26 Thread hans w. koch 
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