thanks johannes,
for the clarification! always better to know, there is no magic involved :-) (though i wasn´t implying [text] but the .txt format, which i believed to be “external" to pd, if that makes sense - appearantly not).
as long as there are workarounds, i can live with that. a fix is quite likely waaayyy beyond my capabilities. but would it warrant opening an issue on github? i am a bit shy for finding the correct wording…
best
hans
Am 20.09.2020 um 17:32 schrieb IOhannes m zmölnig zmoelnig@iem.at:
Am 20. September 2020 16:41:56 MESZ schrieb "hans w. koch" hansw.koch@gmail.com:
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.
hmm, no. the behaviour you are seeing is exactly because [text] does NOT do any behind the scenes magic.
all the problems come from the fact that the default string-representation (and only the string-representation) of numbers is too coarse for double-precision.
mfg.hft.fsl IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list