Re: [PD] problem with correct numbers in pd double precision / problem with div and mod

2020-09-23 Thread hans w. koch 
done: https://github.com/pure-data/pure-data/issues/1150

> Am 23.09.2020 um 18:29 schrieb hans w. koch :
> 
> ack, yes, of course…thanks, martin!
> 
> meaning that [div] and [mod] are not “doublified“ yet.
> i gues that warrants an entry in issues.
> 
>> Am 23.09.2020 um 17:27 schrieb Martin Peach :
>> 
>> On Wed, Sep 23, 2020 at 11:19 AM hans w. koch  wrote:
>>> .
>>> but they only go until 2147483647
>>> anything special about this number?
>> 
>> https://en.wikipedia.org/wiki/2,147,483,647#In_computing
> 




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision / problem with div and mod

2020-09-23 Thread hans w. koch 
ack, yes, of course…thanks, martin!

meaning that [div] and [mod] are not “doublified“ yet.
i gues that warrants an entry in issues.

> Am 23.09.2020 um 17:27 schrieb Martin Peach :
> 
> On Wed, Sep 23, 2020 at 11:19 AM hans w. koch  wrote:
>> .
>> but they only go until 2147483647
>> anything special about this number?
> 
> https://en.wikipedia.org/wiki/2,147,483,647#In_computing




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision / problem with div and mod

2020-09-23 Thread Martin Peach 
On Wed, Sep 23, 2020 at 11:19 AM hans w. koch  wrote:
>.
> but they only go until 2147483647
> anything special about this number?

https://en.wikipedia.org/wiki/2,147,483,647#In_computing



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision / problem with div and mod

2020-09-23 Thread hans w. koch 
the onyl thing i don´t like about the [makefilename %.0f] method is, that for 
big amount of data, it may clutter the symboltable.

so i started investigating alternativ ways of storing big numbers in chunks, 
using the [div] and [mod] objects.
but they only go until 2147483647 after which they overflow and produce wrong 
results.

anything special about this number? seems [div] and [mod] are not fully double 
yet.
demo patch attached

hans



big-numbers4_div-mod.pd
Description: Binary data


> Am 23.09.2020 um 10:34 schrieb hans w. koch :
> 
> lucas thanks for alerting me to
>> Attached patch edited to show that it is "no go" using txt files.
> its indeed a major headache :-(
> conclusion: the only reliable way using [text] with big numbers is with 
> from/tosymbol.
> 
> i totally agree, it would be good to be able to write/read 64bit-arrays.
> what i like about [text] is multi column data - though it gets really slow 
> with bigger files.
> 
> hans
> 
>> Am 21.09.2020 um 10:46 schrieb Lucas Cordiviola :
>> 
>> On 9/20/2020 2:38 PM, hans w. koch wrote:
>>> but would it warrant opening an issue on github?
>> 
>> There should be some way to write/read 64bit arrays in Pd-double. [text] can 
>> be used for other stuff as it is not really efficient inside Pd (even if it 
>> worked without the actual issues).
>> 
>> I think the easiest feature request could be adding [soundfiler] the ability 
>> to "write" with the -raw flag (actually is only for "reading") and also 
>> making it able to handle 8 bytes per value.
>> 
>> A little discussion here might lead Hans or me to issue some request.
>> 
>> ?
>> 
>> 
>> Attached patch edited to show that it is "no go" using txt files.
>> 
>> 
>> 
>> Mensaje telepatico asistido por maquinas.
>> 
>> ___
>> 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] problem with correct numbers in pd double precision

2020-09-23 Thread hans w. koch 
lucas thanks for alerting me to
> Attached patch edited to show that it is "no go" using txt files.
its indeed a major headache :-(
conclusion: the only reliable way using [text] with big numbers is with 
from/tosymbol.

i totally agree, it would be good to be able to write/read 64bit-arrays.
what i like about [text] is multi column data - though it gets really slow with 
bigger files.

hans

> Am 21.09.2020 um 10:46 schrieb Lucas Cordiviola :
> 
> On 9/20/2020 2:38 PM, hans w. koch wrote:
>> but would it warrant opening an issue on github?
> 
> There should be some way to write/read 64bit arrays in Pd-double. [text] can 
> be used for other stuff as it is not really efficient inside Pd (even if it 
> worked without the actual issues).
> 
> I think the easiest feature request could be adding [soundfiler] the ability 
> to "write" with the -raw flag (actually is only for "reading") and also 
> making it able to handle 8 bytes per value.
> 
> A little discussion here might lead Hans or me to issue some request.
> 
> ?
> 
> 
> Attached patch edited to show that it is "no go" using txt files.
> 
> 
> 
> Mensaje telepatico asistido por maquinas.
> 
> ___
> 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] problem with correct numbers in pd double precision

2020-09-21 Thread Lucas Cordiviola 

On 9/20/2020 2:38 PM, hans w. koch wrote:

but would it warrant opening an issue on github?


There should be some way to write/read 64bit arrays in Pd-double. [text] 
can be used for other stuff as it is not really efficient inside Pd 
(even if it worked without the actual issues).


I think the easiest feature request could be adding [soundfiler] the 
ability to "write" with the -raw flag (actually is only for "reading") 
and also making it able to handle 8 bytes per value.


A little discussion here might lead Hans or me to issue some request.

?


Attached patch edited to show that it is "no go" using txt files.



Mensaje telepatico asistido por maquinas.

#N canvas 100 12 1052 660 12;
#X obj 33 196 text set bign;
#X obj 34 106 makefilename %.0f;
#X msg 63 170 0;
#X obj 30 296 text get bign;
#X msg 30 270 0;
#X obj 34 135 t a b;
#X text 31 35 1) store the number in text;
#X msg 270 70 write bign.txt;
#X msg 435 66 read bign.txt;
#X msg 580 65 clear;
#X obj 304 289 text get bign;
#X msg 304 263 0;
#X obj 336 349 makefilename %.0f;
#X obj 335 377 print good;
#X obj 304 410 print good2;
#X obj 30 326 route float symbol;
#X obj 30 403 print float;
#X obj 91 370 print symbol;
#X obj 304 319 t f f;
#X text 301 237 5) now its a float \, but sill contains all digits
;
#X obj 271 99 text define -k bign;
#A set 3.02875e+014 \; 3.02875e+014 \;;
#X msg 35 55 13;
#X obj 35 81 pow 13;
#X text 411 267 6) this stays consistent ONLY with reloading the .txt
;
#X text 434 284 otherwise it "degrades" upon iterated open/save/close/reopen
;
#X obj 604 539 text set bign;
#X obj 605 449 makefilename %.0f;
#X obj 605 478 t a b;
#X msg 604 359 13;
#X obj 604 385 pow 13;
#X msg 634 513 1;
#X obj 604 416 + 1;
#X text 670 354 7) add this number at index 1;
#X text 705 392 8) write to disk;
#X text 738 418 9) read back in;
#X text 266 42 2) write to disk;
#X text 432 32 3) read back in;
#X text 777 525 good: symbol "3028750";
#X text 766 462 9) go to step 5;
#X text 775 500 now we lost precision on index 0:;
#X text 605 320 further more--;
#X text 28 242 4) verify \, that its a symbol;
#X text 26 8 this patch is for Pd-double;
#X text 601 599 more: There should be a way to store 64bit arrays;
#X text 598 578 10);
#N canvas 288 20 816 652 more 0;
#X msg 144 189 13;
#X obj 144 215 pow 13;
#X obj 79 214 until;
#X obj 76 269 +;
#X msg 77 240 1;
#X obj 68 407 array set bna;
#X obj 97 347 +;
#X msg 98 324 1;
#X obj 96 373 t f f;
#X obj 74 296 t f b f;
#X msg 215 206 -1;
#X msg 79 188 10;
#X obj 114 149 t b b b;
#X obj 107 99 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 442 20 array define bna 10;
#X obj 96 502 array get bna;
#X floatatom 94 472 5 0 0 0 - - -;
#X obj 97 532 makefilename %0.f;
#X obj 98 563 print;
#X obj 350 314 soundfiler;
#X msg 357 230 write -wave -bytes 4 bignarray.wav bna;
#X msg 366 268 read bignarray.wav bna;
#X msg 353 110 write -raw 0 1 8 l bignarray bna;
#X text 334 158 currently writing with -raw is not possible \, is only
for reading and is not possible yet to read/write at 8 bytes.;
#X text 329 73 should be something like writing a raw 64bit(8 bytes)
per sample file:, f 61;
#X connect 0 0 1 0;
#X connect 1 0 3 1;
#X connect 2 0 4 0;
#X connect 3 0 9 0;
#X connect 4 0 3 0;
#X connect 6 0 8 0;
#X connect 7 0 6 0;
#X connect 8 0 5 1;
#X connect 8 1 6 1;
#X connect 9 0 5 0;
#X connect 9 1 7 0;
#X connect 9 2 3 1;
#X connect 10 0 6 1;
#X connect 11 0 2 0;
#X connect 12 0 11 0;
#X connect 12 1 0 0;
#X connect 12 2 10 0;
#X connect 13 0 12 0;
#X connect 15 0 17 0;
#X connect 16 0 15 0;
#X connect 17 0 18 0;
#X connect 20 0 19 0;
#X connect 21 0 19 0;
#X restore 600 627 pd more;
#X connect 1 0 5 0;
#X connect 2 0 0 1;
#X connect 3 0 15 0;
#X connect 4 0 3 0;
#X connect 5 0 0 0;
#X connect 5 1 2 0;
#X connect 7 0 20 0;
#X connect 8 0 20 0;
#X connect 9 0 20 0;
#X connect 10 0 18 0;
#X connect 11 0 10 0;
#X connect 12 0 13 0;
#X connect 15 0 16 0;
#X connect 15 1 17 0;
#X connect 18 0 14 0;
#X connect 18 1 12 0;
#X connect 21 0 22 0;
#X connect 22 0 1 0;
#X connect 26 0 27 0;
#X connect 27 0 25 0;
#X connect 27 1 30 0;
#X connect 28 0 29 0;
#X connect 29 0 31 0;
#X connect 30 0 25 1;
#X connect 31 0 26 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision

2020-09-20 Thread hans w. koch 
thanks johannes,

for the clarification! 
always better to know, there is no magic involved :-)
(though i wasn´t implying [text] but the .txt format, which i believed to be 
“external" to pd, if that makes sense - appearantly not).

as long as there are workarounds, i can live with that.
a fix is quite likely waaayyy beyond my capabilities.
but would it warrant opening an issue on github?
i am a bit shy for finding the correct wording…

best

hans


> Am 20.09.2020 um 17:32 schrieb IOhannes m zmölnig :
> 
> Am 20. September 2020 16:41:56 MESZ schrieb "hans w. koch" 
> :
>> yeah, this is consistent with my findings too…
>> it just mystifies me, why writing the contents of [text] containing
>> symbols to a .txt file and reloading converts them silently back to
>> floats, perserving precision.
>> seems like the .txt file format does some behind-the-scenes magic.
> 
> 
> hmm, no.
> the behaviour you are seeing is exactly because [text] does NOT do any behind 
> the scenes magic.
> 
> all the problems come from the fact that the default string-representation 
> (and only the string-representation) of numbers is too coarse for 
> double-precision.
> 
> 
> mfg.hft.fsl
> IOhannes
> 
> 
> ___
> 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] problem with correct numbers in pd double precision

2020-09-20 Thread IOhannes m zmölnig 
Am 20. September 2020 16:41:56 MESZ schrieb "hans w. koch" 
:
> yeah, this is consistent with my findings too…
> it just mystifies me, why writing the contents of [text] containing
> symbols to a .txt file and reloading converts them silently back to
> floats, perserving precision.
> seems like the .txt file format does some behind-the-scenes magic.


hmm, no.
the behaviour you are seeing is exactly because [text] does NOT do any behind 
the scenes magic.

all the problems come from the fact that the default string-representation (and 
only the string-representation) of numbers is too coarse for double-precision.


mfg.hft.fsl
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision

2020-09-20 Thread hans w. koch 
yeah, this is consistent with my findings too…
it just mystifies me, why writing the contents of [text] containing symbols to 
a .txt file and reloading converts them silently back to floats, perserving 
precision.
seems like the .txt file format does some behind-the-scenes magic.

(adapted your patch to demonstrate, also Pd-double only)

hans



big-numbers2.pd
Description: Binary data



> Am 20.09.2020 um 12:40 schrieb Lucas Cordiviola :
> 
> Interesting I got into troubles storing big numbers into a [text] using the 
> -k flag but this can be solved using [list fromsymbol] / [list tosymbol].
> 
> See attached patch (needs Pd-double).
> 
> 
> --
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 9/19/2020 3:38 PM, hans w. koch wrote:
>> just to report another weirdness:
>> if i
>> 1. write those big numbers  (e.g. 8278095582780955) with [text set] to a 
>> [text define ] with [makefilename %.0f] (i used this to avoid unnecessary 
>> decimal points)
>> 2. then write the textfile to disk as .txt
>> 3. read it in again
>> the symbols are automatically converted to exponential notation (8.2781e+15) 
>> inside the [text]/textfile, BUT retain their full precision!
>> 
>> but in order for this to work, they have to be written to the [text] as 
>> symbols with [makefilename %.0f] first.
>> 
>> weird, ain´t it?
>> 
>> hans
>> 
>> 
>> 
>>> Am 19.09.2020 um 10:49 schrieb hans w. koch :
>>> 
>>> arrghhh…sometimes live can be so easy :-)
>>> 
>>> cheers
>>> hans
>>> 
 Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola :
 
 I think you can convert symbol back to float just using [f ].
 
 [123123123(
 |
 [makefilename %f]
 |
 [t a 0]
 | |
 [text set foo]
 
 
 
 [0(
 |
 [text get foo]
 |
 [f ]
 |
 [print]
 
 
 :)
 
 Mensaje telepatico asistido por maquinas.
 
 On 9/19/2020 4:16 AM, hans w. koch wrote:
> thanks lucas,
> 
> transitioning numbers over to symbolland could solve my problem, 
> interesting to know.
> 
> i need to store some of the big numbers in a textfile and there i get the 
> same problems with representation.
> if i recall them later, they´ve lost their precision.
> so i can make the transition back from symboldland with a bit of fudi 
> objects voodoo and be good :-)
> 
> what i use is this:
> [makefilename %f]
> |
> [list trim symbol]
> |
> [fudiformat -u]
> |
> [fudiparse]
> 
> and have my number back from symbol.
> 
> best
> hans
> 
> 
> 
>> Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :
>> 
>> If you want to print the numbers nicely to the console add [makefilename 
>> %f] :
>> 
>> [t b f]
>>  |
>>  [makefilename %f]
>>  |
>>  [print count]
>> 
>> 
>> Be aware of https://github.com/pure-data/pure-data/issues/812
>> 
>> :)
>> 
>> Mensaje telepatico asistido por maquinas.
>> 
>> On 9/18/2020 6:12 PM, hans w. koch wrote:
>>> hello,
>>> 
>>> its probably due to my lack of understanding the correct number 
>>> representations, but here it goes anyway:
>>> 
>>> i compiled pd 51-2 double precision for mac 10.14.6
>>> with this version i was hoping to do some maths on big numbers.
>>> but already an increment of 1 on some moderatly big number gives me 
>>> problems of representation.
>>> 
>>> i made a simple version of the problem as a patch.
>>> to verify you have a working version of pd double, it contains a simple 
>>> test.
>>> and then an iterative addition +1 starting from 99.
>>> i get this:
>>> count: 99
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1.0e+06
>>> count: 1.1e+06
>>> count: 1.1e+06
>>> count: 1.1e+06
>>> 
>>> the algorith terminates succesfully by a [select] after 10 iterations, 
>>> but the results don´t show what i expect.
>>> this to me indicates, that the internal numbers are correct, but they 
>>> don´t “surface” as such.
>>> 
>>> i would be grateful for any pointers and possible workarounds, as the 
>>> numbers i hope to be dealing with are potentially orders of magnitude 
>>> higher.
>>> 
>>> 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

Re: [PD] problem with correct numbers in pd double precision

2020-09-20 Thread Lucas Cordiviola 
Interesting I got into troubles storing big numbers into a [text] using 
the -k flag but this can be solved using [list fromsymbol] / [list 
tosymbol].


See attached patch (needs Pd-double).


--

Mensaje telepatico asistido por maquinas.

On 9/19/2020 3:38 PM, hans w. koch wrote:

just to report another weirdness:
if i
1. write those big numbers  (e.g. 8278095582780955) with [text set] to a [text 
define ] with [makefilename %.0f] (i used this to avoid unnecessary decimal 
points)
2. then write the textfile to disk as .txt
3. read it in again
the symbols are automatically converted to exponential notation (8.2781e+15) 
inside the [text]/textfile, BUT retain their full precision!

but in order for this to work, they have to be written to the [text] as symbols 
with [makefilename %.0f] first.

weird, ain´t it?

hans




Am 19.09.2020 um 10:49 schrieb hans w. koch :

arrghhh…sometimes live can be so easy :-)

cheers
hans


Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola :

I think you can convert symbol back to float just using [f ].

[123123123(
|
[makefilename %f]
|
[t a 0]
| |
[text set foo]



[0(
|
[text get foo]
|
[f ]
|
[print]


:)

Mensaje telepatico asistido por maquinas.

On 9/19/2020 4:16 AM, hans w. koch wrote:

thanks lucas,

transitioning numbers over to symbolland could solve my problem, interesting to 
know.

i need to store some of the big numbers in a textfile and there i get the same 
problems with representation.
if i recall them later, they´ve lost their precision.
so i can make the transition back from symboldland with a bit of fudi objects 
voodoo and be good :-)

what i use is this:
[makefilename %f]
|
[list trim symbol]
|
[fudiformat -u]
|
[fudiparse]

and have my number back from symbol.

best
hans




Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :

If you want to print the numbers nicely to the console add [makefilename %f] :

[t b f]
  |
  [makefilename %f]
  |
  [print count]


Be aware of https://github.com/pure-data/pure-data/issues/812

:)

Mensaje telepatico asistido por maquinas.

On 9/18/2020 6:12 PM, hans w. koch wrote:

hello,

its probably due to my lack of understanding the correct number 
representations, but here it goes anyway:

i compiled pd 51-2 double precision for mac 10.14.6
with this version i was hoping to do some maths on big numbers.
but already an increment of 1 on some moderatly big number gives me problems of 
representation.

i made a simple version of the problem as a patch.
to verify you have a working version of pd double, it contains a simple test.
and then an iterative addition +1 starting from 99.
i get this:
count: 99
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1.0e+06
count: 1.1e+06
count: 1.1e+06
count: 1.1e+06

the algorith terminates succesfully by a [select] after 10 iterations, but the 
results don´t show what i expect.
this to me indicates, that the internal numbers are correct, but they don´t 
“surface” as such.

i would be grateful for any pointers and possible workarounds, as the numbers i 
hope to be dealing with are potentially orders of magnitude higher.

thanks hans


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list 

#N canvas 213 65 898 584 12;
#X obj 330 289 text set bign;
#X obj 203 108 makefilename %.0f;
#X msg 360 263 0;
#X obj 496 414 text get bign;
#X msg 499 387 0;
#X obj 89 190 list fromsymbol;
#X obj 81 468 list tosymbol;
#X obj 86 288 text set bign;
#X obj 91 224 t l b;
#X msg 120 257 1;
#X obj 331 228 t a b;
#X obj 82 443 text get bign;
#X msg 82 418 1;
#X obj 83 490 print good;
#X obj 489 509 print bad;
#N canvas 0 50 985 489 other_tests_failed 0;
#X obj 78 325 array define bn 10;
#X obj 29 92 array set bn;
#X obj 211 148 array get bn;
#X obj 39 41 t l b;
#X msg 70 68 0;
#X floatatom 226 73 5 0 0 0 - - -;
#X obj 223 97 t f b;
#X msg 253 124 1;
#X msg 94 270 write bn.txt;
#X obj 218 224 print;
#X msg 94 298 read bn.txt;
#X obj 536 321 soundfiler;
#X msg 555 260 write -ascii -bytes 4 bnascii.txt bn;
#X msg 564 287 read bnascii.txt bn;
#X msg 40 14 1.23123e+008 4.56456e+008 7.8979e+008;
#X obj 210 178 makefilename %.0f;
#X text 523 161 this was tested with PR #855 "soundfile updates: refactor
\, bugfixes \, AIFC \, & CAF".;
#X connect 2 0 15 0;
#X connect 3 0 1 0;
#X connect 3 1 4 0;
#X connect 4 0 1 1;
#X connect 5 0 6 0;
#X connect 6 0 2 0;
#X connect 6 1 7 0;
#X connect 7 0 2 1;
#X connect 8 0 0 0;
#X connect 10 0 0 0;
#X connect 12 0 11 0;
#X connect 13 0 11 0;
#X connect 14 0 3 0;
#X connect 15 0 9 0;
#X restore 702 545 pd other_tests_failed;
#X obj 202 139 t b a a;
#X obj 204 83 pow 12;
#X msg 204 57 12;
#X obj 490 481 makefilename %.0f;
#X obj 623 98 text define -k bign;
#A set 8.9161e+012 \; 56 57 49 54 49 48 48 52 52 56 50 53 54 \;;
#X obj 352 505 print bad2;
#X obj 465 443 t a

Re: [PD] problem with correct numbers in pd double precision

2020-09-19 Thread hans w. koch 
just to report another weirdness:
if i 
1. write those big numbers  (e.g. 8278095582780955) with [text set] to a [text 
define ] with [makefilename %.0f] (i used this to avoid unnecessary decimal 
points)
2. then write the textfile to disk as .txt
3. read it in again
the symbols are automatically converted to exponential notation (8.2781e+15) 
inside the [text]/textfile, BUT retain their full precision!

but in order for this to work, they have to be written to the [text] as symbols 
with [makefilename %.0f] first.

weird, ain´t it?

hans



> Am 19.09.2020 um 10:49 schrieb hans w. koch :
> 
> arrghhh…sometimes live can be so easy :-)
> 
> cheers 
> hans
> 
>> Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola :
>> 
>> I think you can convert symbol back to float just using [f ].
>> 
>> [123123123(
>> |
>> [makefilename %f]
>> |
>> [t a 0]
>> | |
>> [text set foo]
>> 
>> 
>> 
>> [0(
>> |
>> [text get foo]
>> |
>> [f ]
>> |
>> [print]
>> 
>> 
>> :)
>> 
>> Mensaje telepatico asistido por maquinas.
>> 
>> On 9/19/2020 4:16 AM, hans w. koch wrote:
>>> thanks lucas,
>>> 
>>> transitioning numbers over to symbolland could solve my problem, 
>>> interesting to know.
>>> 
>>> i need to store some of the big numbers in a textfile and there i get the 
>>> same problems with representation.
>>> if i recall them later, they´ve lost their precision.
>>> so i can make the transition back from symboldland with a bit of fudi 
>>> objects voodoo and be good :-)
>>> 
>>> what i use is this:
>>> [makefilename %f]
>>> |
>>> [list trim symbol]
>>> |
>>> [fudiformat -u]
>>> |
>>> [fudiparse]
>>> 
>>> and have my number back from symbol.
>>> 
>>> best
>>> hans
>>> 
>>> 
>>> 
 Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :
 
 If you want to print the numbers nicely to the console add [makefilename 
 %f] :
 
 [t b f]
  |
  [makefilename %f]
  |
  [print count]
 
 
 Be aware of https://github.com/pure-data/pure-data/issues/812
 
 :)
 
 Mensaje telepatico asistido por maquinas.
 
 On 9/18/2020 6:12 PM, hans w. koch wrote:
> hello,
> 
> its probably due to my lack of understanding the correct number 
> representations, but here it goes anyway:
> 
> i compiled pd 51-2 double precision for mac 10.14.6
> with this version i was hoping to do some maths on big numbers.
> but already an increment of 1 on some moderatly big number gives me 
> problems of representation.
> 
> i made a simple version of the problem as a patch.
> to verify you have a working version of pd double, it contains a simple 
> test.
> and then an iterative addition +1 starting from 99.
> i get this:
> count: 99
> count: 1e+06
> count: 1e+06
> count: 1e+06
> count: 1e+06
> count: 1e+06
> count: 1.0e+06
> count: 1.1e+06
> count: 1.1e+06
> count: 1.1e+06
> 
> the algorith terminates succesfully by a [select] after 10 iterations, 
> but the results don´t show what i expect.
> this to me indicates, that the internal numbers are correct, but they 
> don´t “surface” as such.
> 
> i would be grateful for any pointers and possible workarounds, as the 
> numbers i hope to be dealing with are potentially orders of magnitude 
> higher.
> 
> 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

Re: [PD] problem with correct numbers in pd double precision

2020-09-19 Thread hans w. koch 
arrghhh…sometimes live can be so easy :-)

cheers 
hans

> Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola :
> 
> I think you can convert symbol back to float just using [f ].
> 
> [123123123(
> |
> [makefilename %f]
> |
> [t a 0]
> | |
> [text set foo]
> 
> 
> 
> [0(
> |
> [text get foo]
> |
> [f ]
> |
> [print]
> 
> 
> :)
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 9/19/2020 4:16 AM, hans w. koch wrote:
>> thanks lucas,
>> 
>> transitioning numbers over to symbolland could solve my problem, interesting 
>> to know.
>> 
>> i need to store some of the big numbers in a textfile and there i get the 
>> same problems with representation.
>> if i recall them later, they´ve lost their precision.
>> so i can make the transition back from symboldland with a bit of fudi 
>> objects voodoo and be good :-)
>> 
>> what i use is this:
>> [makefilename %f]
>> |
>> [list trim symbol]
>> |
>> [fudiformat -u]
>> |
>> [fudiparse]
>> 
>> and have my number back from symbol.
>> 
>> best
>> hans
>> 
>> 
>> 
>>> Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :
>>> 
>>> If you want to print the numbers nicely to the console add [makefilename 
>>> %f] :
>>> 
>>> [t b f]
>>>   |
>>>   [makefilename %f]
>>>   |
>>>   [print count]
>>> 
>>> 
>>> Be aware of https://github.com/pure-data/pure-data/issues/812
>>> 
>>> :)
>>> 
>>> Mensaje telepatico asistido por maquinas.
>>> 
>>> On 9/18/2020 6:12 PM, hans w. koch wrote:
 hello,
 
 its probably due to my lack of understanding the correct number 
 representations, but here it goes anyway:
 
 i compiled pd 51-2 double precision for mac 10.14.6
 with this version i was hoping to do some maths on big numbers.
 but already an increment of 1 on some moderatly big number gives me 
 problems of representation.
 
 i made a simple version of the problem as a patch.
 to verify you have a working version of pd double, it contains a simple 
 test.
 and then an iterative addition +1 starting from 99.
 i get this:
 count: 99
 count: 1e+06
 count: 1e+06
 count: 1e+06
 count: 1e+06
 count: 1e+06
 count: 1.0e+06
 count: 1.1e+06
 count: 1.1e+06
 count: 1.1e+06
 
 the algorith terminates succesfully by a [select] after 10 iterations, but 
 the results don´t show what i expect.
 this to me indicates, that the internal numbers are correct, but they 
 don´t “surface” as such.
 
 i would be grateful for any pointers and possible workarounds, as the 
 numbers i hope to be dealing with are potentially orders of magnitude 
 higher.
 
 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

Re: [PD] problem with correct numbers in pd double precision

2020-09-19 Thread Lucas Cordiviola 

I think you can convert symbol back to float just using [f ].

[123123123(
|
[makefilename %f]
|
[t a 0]
| |
[text set foo]



[0(
|
[text get foo]
|
[f ]
|
[print]


:)

Mensaje telepatico asistido por maquinas.

On 9/19/2020 4:16 AM, hans w. koch wrote:

thanks lucas,

transitioning numbers over to symbolland could solve my problem, interesting to 
know.

i need to store some of the big numbers in a textfile and there i get the same 
problems with representation.
if i recall them later, they´ve lost their precision.
so i can make the transition back from symboldland with a bit of fudi objects 
voodoo and be good :-)

what i use is this:
[makefilename %f]
|
[list trim symbol]
|
[fudiformat -u]
|
[fudiparse]

and have my number back from symbol.

best
hans




Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :

If you want to print the numbers nicely to the console add [makefilename %f] :

[t b f]
   |
   [makefilename %f]
   |
   [print count]


Be aware of https://github.com/pure-data/pure-data/issues/812

:)

Mensaje telepatico asistido por maquinas.

On 9/18/2020 6:12 PM, hans w. koch wrote:

hello,

its probably due to my lack of understanding the correct number 
representations, but here it goes anyway:

i compiled pd 51-2 double precision for mac 10.14.6
with this version i was hoping to do some maths on big numbers.
but already an increment of 1 on some moderatly big number gives me problems of 
representation.

i made a simple version of the problem as a patch.
to verify you have a working version of pd double, it contains a simple test.
and then an iterative addition +1 starting from 99.
i get this:
count: 99
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1.0e+06
count: 1.1e+06
count: 1.1e+06
count: 1.1e+06

the algorith terminates succesfully by a [select] after 10 iterations, but the 
results don´t show what i expect.
this to me indicates, that the internal numbers are correct, but they don´t 
“surface” as such.

i would be grateful for any pointers and possible workarounds, as the numbers i 
hope to be dealing with are potentially orders of magnitude higher.

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

Re: [PD] problem with correct numbers in pd double precision

2020-09-19 Thread hans w. koch 
thanks lucas,

transitioning numbers over to symbolland could solve my problem, interesting to 
know.

i need to store some of the big numbers in a textfile and there i get the same 
problems with representation.
if i recall them later, they´ve lost their precision.
so i can make the transition back from symboldland with a bit of fudi objects 
voodoo and be good :-)

what i use is this:
[makefilename %f]
|
[list trim symbol]
|
[fudiformat -u]
|
[fudiparse]

and have my number back from symbol.

best
hans



> Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :
> 
> If you want to print the numbers nicely to the console add [makefilename %f] :
> 
> [t b f]
>   |
>   [makefilename %f]
>   |
>   [print count]
> 
> 
> Be aware of https://github.com/pure-data/pure-data/issues/812
> 
> :)
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 9/18/2020 6:12 PM, hans w. koch wrote:
>> hello,
>> 
>> its probably due to my lack of understanding the correct number 
>> representations, but here it goes anyway:
>> 
>> i compiled pd 51-2 double precision for mac 10.14.6
>> with this version i was hoping to do some maths on big numbers.
>> but already an increment of 1 on some moderatly big number gives me problems 
>> of representation.
>> 
>> i made a simple version of the problem as a patch.
>> to verify you have a working version of pd double, it contains a simple test.
>> and then an iterative addition +1 starting from 99.
>> i get this:
>> count: 99
>> count: 1e+06
>> count: 1e+06
>> count: 1e+06
>> count: 1e+06
>> count: 1e+06
>> count: 1.0e+06
>> count: 1.1e+06
>> count: 1.1e+06
>> count: 1.1e+06
>> 
>> the algorith terminates succesfully by a [select] after 10 iterations, but 
>> the results don´t show what i expect.
>> this to me indicates, that the internal numbers are correct, but they don´t 
>> “surface” as such.
>> 
>> i would be grateful for any pointers and possible workarounds, as the 
>> numbers i hope to be dealing with are potentially orders of magnitude higher.
>> 
>> 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

Re: [PD] problem with correct numbers in pd double precision

2020-09-18 Thread Lucas Cordiviola 
If you want to print the numbers nicely to the console add [makefilename 
%f] :


[t b f]
  |
      [makefilename %f]
      |
      [print count]


Be aware of https://github.com/pure-data/pure-data/issues/812

:)

Mensaje telepatico asistido por maquinas.

On 9/18/2020 6:12 PM, hans w. koch wrote:

hello,

its probably due to my lack of understanding the correct number 
representations, but here it goes anyway:


i compiled pd 51-2 double precision for mac 10.14.6
with this version i was hoping to do some maths on big numbers.
but already an increment of 1 on some moderatly big number gives me 
problems of representation.


i made a simple version of the problem as a patch.
to verify you have a working version of pd double, it contains a 
simple test.

and then an iterative addition +1 starting from 99.
i get this:
count: 99
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1.0e+06
count: 1.1e+06
count: 1.1e+06
count: 1.1e+06

the algorith terminates succesfully by a [select] after 10 iterations, 
but the results don´t show what i expect.
this to me indicates, that the internal numbers are correct, but they 
don´t “surface” as such.


i would be grateful for any pointers and possible workarounds, as the 
numbers i hope to be dealing with are potentially orders of magnitude 
higher.


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] problem with correct numbers in pd double precision

2020-09-18 Thread hans w. koch 
hello,

its probably due to my lack of understanding the correct number 
representations, but here it goes anyway:

i compiled pd 51-2 double precision for mac 10.14.6
with this version i was hoping to do some maths on big numbers.
but already an increment of 1 on some moderatly big number gives me problems of 
representation.

i made a simple version of the problem as a patch.
to verify you have a working version of pd double, it contains a simple test.
and then an iterative addition +1 starting from 99.
i get this:
count: 99
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1.0e+06
count: 1.1e+06
count: 1.1e+06
count: 1.1e+06

the algorith terminates succesfully by a [select] after 10 iterations, but the 
results don´t show what i expect.
this to me indicates, that the internal numbers are correct, but they don´t 
“surface” as such.

i would be grateful for any pointers and possible workarounds, as the numbers i 
hope to be dealing with are potentially orders of magnitude higher.

thanks hans




pd_double_numberproblem.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list