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