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
Am 20.09.2020 um 12:40 schrieb Lucas Cordiviola lucarda27@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
- 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)
- then write the textfile to disk as .txt
- 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.koch@gmail.com:
arrghhh…sometimes live can be so easy :-)
cheers hans
Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola lucarda27@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 lucarda27@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>