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
The output looks entirely reasonable. Maybe your spreadsheet application
expects floating pointer numbers in the German format (comma instead dot)? If
yes, there surely is an option to change that. Either way, the problem is not
on the side of Pd.
Am 9. Mai 2021, 18:36, um 18:36,
Christof Ressi schreef op 09-05-2021 13:40:
>Can you share the output?
here's a small part of it.
putting the textfile into a spreadsheet (OpenOffice)
only the %d data is seen as numbers.
with [makefilename %d]
49
64
81
100
121
144
169
with [makefilename %.2f]
49.00
64.00
81.00
100.00
Can you share the output?
Am 9. Mai 2021, 13:21, um 13:21, ro...@dds.nl schrieb:
>thanks for the answers.
>
>i'm not asking about double-precision here.
>
>@Christof
>
> [makefilename %d] together with [text] works: in the spreadsheet the
>'text' in the output file is seen as numbers.
>
>
thanks for the answers.
i'm not asking about double-precision here.
@Christof
[makefilename %d] together with [text] works: in the spreadsheet the
'text' in the output file is seen as numbers.
with [makefilename %f] this is not the case.
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
On Fri, May 7, 2021 at 11:23 AM Christof Ressi 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
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
there have been a few discussions around this last year (in which i was
involved).
1. 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)
2. regarding the makefilename
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
On Fri, May 7, 2021 at 10:17 AM wrote:
>
> hi,
>
> i'm struggling with the way Pd handles numbers bigger then 99.
>
> 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 99 i get the abbreviated
> notation
hi,
i'm struggling with the way Pd handles numbers bigger then 99.
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 99 i get the abbreviated
notation and am loosing the lower digits.
in Pd i can make a
12 matches
Mail list logo
