[PD] problem with correct numbers in pd double precision

hans w. koch hansw.koch at gmail.com
Sat Sep 19 20:38:21 CEST 2020


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>
> 






More information about the Pd-list mailing list