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
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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
arrghhh…sometimes live can be so easy :-)
cheers hans
Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola lucarda27@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
just to report another weirdness: if i
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@gmail.com:
arrghhh…sometimes live can be so easy :-)
cheers hans
Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola lucarda27@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
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
- 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)
- then write the textfile to disk as .txt
- 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@gmail.com:
arrghhh…sometimes live can be so easy :-)
cheers hans
Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola lucarda27@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
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
Am 20.09.2020 um 12:40 schrieb Lucas Cordiviola lucarda27@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
- 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)
- then write the textfile to disk as .txt
- 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@gmail.com:
arrghhh…sometimes live can be so easy :-)
cheers hans
Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola lucarda27@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@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@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>
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
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
On 9/20/2020 2:38 PM, hans w. koch wrote:
but would it warrant opening an issue on github?
There should be some way to write/read 64bit arrays in Pd-double. [text] can be used for other stuff as it is not really efficient inside Pd (even if it worked without the actual issues).
I think the easiest feature request could be adding [soundfiler] the ability to "write" with the -raw flag (actually is only for "reading") and also making it able to handle 8 bytes per value.
A little discussion here might lead Hans or me to issue some request.
?
Attached patch edited to show that it is "no go" using txt files.
Mensaje telepatico asistido por maquinas.
lucas thanks for alerting me to
Attached patch edited to show that it is "no go" using txt files.
its indeed a major headache :-( conclusion: the only reliable way using [text] with big numbers is with from/tosymbol.
i totally agree, it would be good to be able to write/read 64bit-arrays. what i like about [text] is multi column data - though it gets really slow with bigger files.
hans
Am 21.09.2020 um 10:46 schrieb Lucas Cordiviola lucarda27@hotmail.com:
On 9/20/2020 2:38 PM, hans w. koch wrote:
but would it warrant opening an issue on github?
There should be some way to write/read 64bit arrays in Pd-double. [text] can be used for other stuff as it is not really efficient inside Pd (even if it worked without the actual issues).
I think the easiest feature request could be adding [soundfiler] the ability to "write" with the -raw flag (actually is only for "reading") and also making it able to handle 8 bytes per value.
A little discussion here might lead Hans or me to issue some request.
?
Attached patch edited to show that it is "no go" using txt files.
Mensaje telepatico asistido por maquinas.
<big-numbers3.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
the onyl thing i don´t like about the [makefilename %.0f] method is, that for big amount of data, it may clutter the symboltable.
so i started investigating alternativ ways of storing big numbers in chunks, using the [div] and [mod] objects. but they only go until 2147483647 after which they overflow and produce wrong results.
anything special about this number? seems [div] and [mod] are not fully double yet. demo patch attached
hans
Am 23.09.2020 um 10:34 schrieb hans w. koch hansw.koch@gmail.com:
lucas thanks for alerting me to
Attached patch edited to show that it is "no go" using txt files.
its indeed a major headache :-( conclusion: the only reliable way using [text] with big numbers is with from/tosymbol.
i totally agree, it would be good to be able to write/read 64bit-arrays. what i like about [text] is multi column data - though it gets really slow with bigger files.
hans
Am 21.09.2020 um 10:46 schrieb Lucas Cordiviola lucarda27@hotmail.com:
On 9/20/2020 2:38 PM, hans w. koch wrote:
but would it warrant opening an issue on github?
There should be some way to write/read 64bit arrays in Pd-double. [text] can be used for other stuff as it is not really efficient inside Pd (even if it worked without the actual issues).
I think the easiest feature request could be adding [soundfiler] the ability to "write" with the -raw flag (actually is only for "reading") and also making it able to handle 8 bytes per value.
A little discussion here might lead Hans or me to issue some request.
?
Attached patch edited to show that it is "no go" using txt files.
Mensaje telepatico asistido por maquinas.
<big-numbers3.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, Sep 23, 2020 at 11:19 AM hans w. koch hansw.koch@gmail.com wrote:
. but they only go until 2147483647 anything special about this number?
ack, yes, of course…thanks, martin!
meaning that [div] and [mod] are not “doublified“ yet. i gues that warrants an entry in issues.
Am 23.09.2020 um 17:27 schrieb Martin Peach chakekatzil@gmail.com:
On Wed, Sep 23, 2020 at 11:19 AM hans w. koch hansw.koch@gmail.com wrote:
. but they only go until 2147483647 anything special about this number?
done: https://github.com/pure-data/pure-data/issues/1150
Am 23.09.2020 um 18:29 schrieb hans w. koch hansw.koch@gmail.com:
ack, yes, of course…thanks, martin!
meaning that [div] and [mod] are not “doublified“ yet. i gues that warrants an entry in issues.
Am 23.09.2020 um 17:27 schrieb Martin Peach chakekatzil@gmail.com:
On Wed, Sep 23, 2020 at 11:19 AM hans w. koch hansw.koch@gmail.com wrote:
. but they only go until 2147483647 anything special about this number?