[PD] problem with correct numbers in pd double precision

[hans w. koch]

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