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 <lucard...@hotmail.com>: > > 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 <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> > <big-numbers.pd>
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list