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 <zmoel...@iem.at>: > > Am 20. September 2020 16:41:56 MESZ schrieb "hans w. koch" > <hansw.k...@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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
