just to report another weirdness: if i
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