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 <hansw.k...@gmail.com>: > > arrghhh…sometimes live can be so easy :-) > > cheers > hans > >> Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola <lucard...@hotmail.com>: >> >> 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 <lucard...@hotmail.com>: >>>> >>>> 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 999999. >>>>> i get this: >>>>> count: 999999 >>>>> count: 1e+06 >>>>> count: 1e+06 >>>>> count: 1e+06 >>>>> count: 1e+06 >>>>> count: 1e+06 >>>>> count: 1.00000e+06 >>>>> count: 1.00001e+06 >>>>> count: 1.00001e+06 >>>>> count: 1.00001e+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 >>>>> <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