[PD] problem with correct numbers in pd double precision

[hans w. koch]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: big-numbers2.pd
Type: application/octet-stream
Size: 1401 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200920/8020a39d/attachment.obj>
-------------- next part --------------



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