hi,
i'm struggling with the way Pd handles numbers bigger then 999999.
i have an array with thousands of numbers, which i write to a file to analyse them.
however, as soon as a number is bigger then 999999 i get the abbreviated notation and am loosing the lower digits.
in Pd i can make a big number showing all digits by transforming it into a symbol, e.g. with makefilename.
but a thus created text-file does not work in a spreadsheet.
probably there's a way to overcome this seemingly limitation, but i've not found it yet.
anybody with a hint?
rolf
On Fri, May 7, 2021 at 10:17 AM rolfm@dds.nl wrote:
hi,
i'm struggling with the way Pd handles numbers bigger then 999999.
i have an array with thousands of numbers, which i write to a file to analyse them.
however, as soon as a number is bigger then 999999 i get the abbreviated notation and am loosing the lower digits.
This is because Pd rounds all numbers to six significant digits when it writes hem to a file. You could try using two arrays with the most and least significant halves of the numbers in parallel. Or wait for 64-bit Pd....
Martin
If your numbers are integers, you can convert them to symbols with [makefilename %d] and add them to a text file, e.g. with [text set].
If the numbers are floats, you can use [makefilename %f]. Unlike %g, the %f specifier prevents the use of scientific notation. See also https://stackoverflow.com/a/5913115/6063908.
Works for me (tm).
Christof
On 07.05.2021 16:15, rolfm@dds.nl wrote:
hi,
i'm struggling with the way Pd handles numbers bigger then 999999.
i have an array with thousands of numbers, which i write to a file to analyse them.
however, as soon as a number is bigger then 999999 i get the abbreviated notation and am loosing the lower digits.
in Pd i can make a big number showing all digits by transforming it into a symbol, e.g. with makefilename.
but a thus created text-file does not work in a spreadsheet.
probably there's a way to overcome this seemingly limitation, but i've not found it yet.
anybody with a hint?
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
there have been a few discussions around this last year (in which i was involved).
its not about pd 64bit (that is liekly already running on your machine)! its about pd double precision, which is possible to compile easily (as i found out, being a noob)
regarding the makefilename approach: be carefule, if you generate lots of numbers:
https://lists.puredata.info/pipermail/pd-list/2020-10/128229.html
https://lists.puredata.info/pipermail/pd-list/2020-09/128107.html
it ain´t easy…
Am 07.05.2021 um 16:33 schrieb Christof Ressi info@christofressi.com:
If your numbers are integers, you can convert them to symbols with [makefilename %d] and add them to a text file, e.g. with [text set].
If the numbers are floats, you can use [makefilename %f]. Unlike %g, the %f specifier prevents the use of scientific notation. See also https://stackoverflow.com/a/5913115/6063908.
Works for me (tm).
Christof
On 07.05.2021 16:15, rolfm@dds.nl wrote:
hi,
i'm struggling with the way Pd handles numbers bigger then 999999.
i have an array with thousands of numbers, which i write to a file to analyse them.
however, as soon as a number is bigger then 999999 i get the abbreviated notation and am loosing the lower digits.
in Pd i can make a big number showing all digits by transforming it into a symbol, e.g. with makefilename.
but a thus created text-file does not work in a spreadsheet.
probably there's a way to overcome this seemingly limitation, but i've not found it yet.
anybody with a hint?
rolf
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
Thanks for stressing the differences between 64bit and double precision!
However, I think it's not about double precision, either. Single precision only becomes an issue if you need more than 23 bits precision (which is not the case here).
The actual issue is how Pd *prints* floating point numbers when writing text files. It uses the %g print specifier, which automatically switches to scientific notation beyond a certain number of digits. See the implementation of "atom_string".
My example with [makefilename %f] shows that you can indeed print/save numbers with much higher precision - without the need of double precision floating point numbers. But as you have correctly pointed out, excessive use can lead to "symbol table pollution". Note that Pd has recently increased the size of its symbol table by a factor of 16 (https://github.com/pure-data/pure-data/commit/36eefd23d793969d3c5c160d9986e0...), so the problem has been mitigated somehow, but not completely eliminated.
I'm not sure how to solve this... the problem is that "atom_string" is used to *save* and *display* floats, but these two operations don't require the same amount of precision.
I think this has been discussed not too long ago. Maybe IOhannes remembers.
Christof
On 07.05.2021 16:53, hans w. koch wrote:
there have been a few discussions around this last year (in which i was involved).
its not about pd 64bit (that is liekly already running on your machine)! its about pd double precision, which is possible to compile easily (as i found out, being a noob)
regarding the makefilename approach: be carefule, if you generate lots of numbers:
https://lists.puredata.info/pipermail/pd-list/2020-10/128229.html
- (one of) the other discussions: Problem With Correct Numbers In Pd Double Precision
https://lists.puredata.info/pipermail/pd-list/2020-09/128107.html
it ain´t easy…
Am 07.05.2021 um 16:33 schrieb Christof Ressi info@christofressi.com:
If your numbers are integers, you can convert them to symbols with [makefilename %d] and add them to a text file, e.g. with [text set].
If the numbers are floats, you can use [makefilename %f]. Unlike %g, the %f specifier prevents the use of scientific notation. See also https://stackoverflow.com/a/5913115/6063908.
Works for me (tm).
Christof
On 07.05.2021 16:15, rolfm@dds.nl wrote:
hi,
i'm struggling with the way Pd handles numbers bigger then 999999.
i have an array with thousands of numbers, which i write to a file to analyse them.
however, as soon as a number is bigger then 999999 i get the abbreviated notation and am loosing the lower digits.
in Pd i can make a big number showing all digits by transforming it into a symbol, e.g. with makefilename.
but a thus created text-file does not work in a spreadsheet.
probably there's a way to overcome this seemingly limitation, but i've not found it yet.
anybody with a hint?
rolf
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, May 7, 2021 at 11:23 AM Christof Ressi info@christofressi.com wrote:
Thanks for stressing the differences between 64bit and double precision!
The confusion persists though, as double precision is also 64-bit. One has 64-bit address bus width and the other has 64-bit data bus width. '64-bit Pd' appears to refer to the wide address version. So I guess the wide data version is called 'double-precision Pd'? (although it will also use the wide address bus)(the meaning of 'double precision' is too ambiguous for me as it will change over time in a way that '64' hopefully doesn't) Does the 'double-precision Pd' also save its patches to 6 significant digits? It is possible to write an external in 'normal' Pd that manipulates numbers in whatever precision you like, you just can't save the results unless you do so from within the same external.
Martin
One has 64-bit address bus width and the other has 64-bit data bus width.
"double precision" has nothing to do with the data bus width. It just means that "t_float" and "t_sample" are defined as "double" instead of "float".
So "single precision"/"double precision" and "32-bit"/"64-bit" are really orthogonal. In fact, you can build a "32-bit double precision Pd".
Does the 'double-precision Pd' also save its patches to 6 significant digits?
I think so (prove me wrong!), because it foremost depends on the implementation of "%g" for "sprintf".
Christof
On 07.05.2021 18:15, Martin Peach wrote:
On Fri, May 7, 2021 at 11:23 AM Christof Ressi info@christofressi.com wrote:
Thanks for stressing the differences between 64bit and double precision!
The confusion persists though, as double precision is also 64-bit. One has 64-bit address bus width and the other has 64-bit data bus width. '64-bit Pd' appears to refer to the wide address version. So I guess the wide data version is called 'double-precision Pd'? (although it will also use the wide address bus)(the meaning of 'double precision' is too ambiguous for me as it will change over time in a way that '64' hopefully doesn't) Does the 'double-precision Pd' also save its patches to 6 significant digits? It is possible to write an external in 'normal' Pd that manipulates numbers in whatever precision you like, you just can't save the results unless you do so from within the same external.
Martin
On 5/7/21 5:21 PM, Christof Ressi wrote:
I think this has been discussed not too long ago. Maybe IOhannes remembers.
:-)
probably the discussion on [804]
to recap: katja's original double-precision fixes (on which the current double-precision support is based) used different formats for displaying (and saving) numbers, based on whether you were using double precision or not. i intentionally left this format magic out (because it also had undesired side-effects).
I'm not sure how to solve this... the problem is that "atom_string" is used to *save* and *display* floats, but these two operations don't require the same amount of precision.
yep. i agree that we need two different atom2string converters for those two use-cases. it would also solve the problem with spaces-in-symbols [824].
i've opened a feature-request [1310]
gfmsdra IOhannes
[807] https://github.com/pure-data/pure-data/pull/807 [824] https://github.com/pure-data/pure-data/issues/824 [1310] https://github.com/pure-data/pure-data/issues/1310