I remember someone posting a link to a site that had this compiled executable labelled as an "experimental release", but I can't find it now. Maybe it was it on an IEM page? If you know, please tell me where I could download it from.

mmmh that's bad news.
@jameslo do you know these threads? Maybe they help:
https://forum.pdpatchrepo.info/topic/13710/how-to-calculate-with-higher-precision/5
https://forum.pdpatchrepo.info/topic/709/symbol-to-float-conversion/17
Also I think @porres Else has more double stuff, but not sure about this?

@jameslo said:

Aw, the UI still rounds to single-precision, that's no fun! So you still can't store a double-precision float in a message or an array, or display it in a number box

You know, "regular" Pd can't display numbers in single-precision. The display precision is less. For instance, you can represent any number with 7 digits or less in 32-bit float, but Pd can only display 6 significant digits.

I say this because you seem to imply that "regular" Pd can properly display 32-bit float and double precision should display 64-bit values. Know what I mean?

ELSE is not yet compiled for Pd64, as it is not "official" yet. Many objects in Pd single precision can use 'double' in the code internally, but it gets truncated when output.

cheers

@porres said:

Know what I mean?

I do! That also makes me sad, but it's more of a familiar, worn-in sadness. But what this experimental release of Pd64 does is worse by 8 or 9 digits! 3.141592653589793 becomes 3.14159

@jameslo said:

But what this experimental release of Pd64 does is worse by 8 or 9 digits!

It is, and I'm not sure why and how, but I think there's also an issue regarding what you can save on a Pd file and make it compatible I guess? You'd then need to have a special code and Pd file to run Pd64.

Anyway, how does this break your leg?

We can also bring this up to the Pd list and stuff.

@jameslo Try "three point one four one five nine two six five three five eight nine seven nine three".... it works....
The only way I can display (on reloading a patch) a precise number is as a symbol......... so not very useful.
concat.zip
David.

@porres He he he...I gotta remember that expression.

it just makes double-precision less usable, that's all. Most programming languages try to make language features orthogonal, which not only helps with usability but also makes them easier to learn. RE file compatibility, the languages I've used do anything from silently convert from one precision to another, to warning you before they do it, to demanding that you explicitly cast one type to the next. As we've been discussing, Pd already knows how to silently convert, so that might be an option.

I'm not a language designer and I don't know the goals and culture of Pd development, so I'm hesitant to make specific recommendations (or even call them "recommendations"). I'm really just telling you what I naively expected when downloaded this experimental release.

@whale-av The workaround I found is the same one I use in single-precision Pd when I really want to save all 7 digits to disk (uh, I mean "hard drive", uh, I mean "non-volatile memory"), which is to prepend numbers with an escaped space and save them as a symbol in a text object. And to display numbers I've been using [makefile %.15e] with a symbol box.

@jameslo said:

I naively expected when downloaded this experimental release.

I also did, and I think we can raise a discussion on the list on why can't we have the best precision possible for both single and double

yes

12 years ago:
[PD] why does PD round numbers? (in tables, in messageboxes, etc)
https://lists.puredata.info/pipermail/pd-list/2012-04/095892.html

@lacuna @porres OK, we'll see what they say (but being shy I'll leave it to @porres). As far as I know, other programming languages aren't forced to solve the binary-decimal mismatch this way but I've also never imagined a language where a float divided by 0 equals 0 without a complaint!

I wouldn't treat Pd as a 'proper language'

@porres Why not? Or do you just mean it is not safe to expect what is generally safe to expect in programming languages?

@oid said:

Why not?

Because it will break your heart as it draws you in closer and closer.

@porres said:

I also did, and I think we can raise a discussion on the list on why can't we have the best precision possible for both single and double

FWIW: Some years ago, SuperCollider changed double-to-string rendering to 17 digits of precision (sc language uses double precision, while audio is single precision), and... users freaked out because suddenly e.g. 1/10 would print out as 0.10000000000000001. "But it's not exact, where are those extra digits coming from" -- many many user complaints, until we reverted that change and now print 14 digits instead.

That is, "best precision" may not be the same as maximum precision.

Though I'd agree that clamping doubles to single precision in object boxes seems a pointless restriction.

hjh

@ddw_music I love that story but am scratching my head over the 1/10 example you gave. Here's a test I made in Arduino c++:

I went out 40 digits and didn't see anything unexpected. Was that example you gave just a metaphor for the issue, or is my test naive?

Getting back to how Pd seems to differ from other programming languages, I'm going to hazard a guess and say that Pd hasn't separated the value of a float from its display/storage format. In my Arduino code I declare values, but it's not until the print statements that I specify their display formats. It's similar in Java and c#. I wonder if Pd could do something similar without upsetting users or making it too unfriendly? Maybe number boxes and arrays have an extra property that is a numeric format string? Or set messages for messages end in a numeric format string? Format strings shouldn't be too unfamiliar to those who've used makefilename. And if the format string is missing, then Pd defaults to it's current single-precision truncation strategy?

PS I hope my attempt at humor didn't discourage @porres from responding to @oid's question. I'm sure he would have something more meaningful to contribute.

Edit: hmm, but here's Pd64.

Yet another edit: I found this in Microsoft Excel help, but it suggests the value should be slightly less, not more that 0.1. Plus, Excel shows 0.1 exactly.

Yet another edit edit: disregard my comment about expecting it to be less, I didn't account for normalization of the mantissa. Carry on.

@jameslo said:

I hope my attempt at humor didn't discourage @porres from responding to @oid's question. I'm sure he would have something more meaningful to contribute.

not at all I just don't see Pd as a "proper language" and this is the best I can give, sorry

@jameslo said:

@ddw_music I love that story but am scratching my head over the 1/10 example you gave. Here's a test I made in Arduino c++: ... I went out 40 digits and didn't see anything unexpected. Was that example you gave just a metaphor for the issue, or is my test naive?

Not a metaphor at all:

[16, 17, 40].do { |prec|
    "% digits: %\n".postf(
        prec,
        0.1.asStringPrec(prec)
    )
};

16 digits: 0.1
17 digits: 0.10000000000000001
40 digits: 0.1000000000000000055511151231257827021182

As for Arduino, the float datatype reference says "Unlike other platforms, where you can get more precision by using a double (e.g. up to 15 digits), on the Arduino, double is the same size as float" -- so my guess here is that Serial places a limit on the number of digits it will try to render, and then fills the rest with zeros.

I went out 40 digits and didn't see anything unexpected.

Seeing zeros all the way out to 40 digits is unexpected! Arduino's output here is more comforting to end-users (which might be why they did that), but it isn't accurate.

Considering that Arduino calculates "double" using single precision, the output should deviate from the mathematically true value even earlier:

// 0.1.as32Bits = single precision but as an integer
// Float.from32Bits = double precision but based on the 32 bit float
Float.from32Bits(0.1.as32Bits).asStringPrec(40)

-> 0.100000001490116119384765625

The most reasonable conclusion I can draw is that Arduino is gussying up the output to reduce the number of "what the xxx is it printing" questions on their forum. That should not be taken as a standard against which other software libraries may be judged.

Edit: hmm, but here's Pd64.

Pd64 is doing it right, and Arduino is not.

Getting back to how Pd seems to differ from other programming languages, I'm going to hazard a guess and say that Pd hasn't separated the value of a float from its display/storage format.

The value must be stored in standard single/double precision format. You need the CPU to be able to take advantage of floating point instructions.

It's rather that Pd has to render the arguments as text, and this part isn't syncing up with the "double" compiler switch.

PS I hope my attempt at humor didn't discourage @porres from responding to @oid's question. I'm sure he would have something more meaningful to contribute.

Of patchers as programming languages... well, I got a lot of opinions about that. Another time. For now, just to say, classical algorithms are much harder to express in patchers because patchers are missing a few key features of programming languages.

hjh

@ddw_music This doesn't invalidate your larger point, but RE double precision floating point on Arduino, that reference is needs updating. I used a MKR Zero because it supports 8 byte doubles. You can see in my code that line 12 reports that the size of a double is 8 bytes, and that line 15 generates 16 correct digits of pi.

For fun I tested c# (which agrees with SC and Pd64) and Java (which agrees with Arduino) so I'm not quite ready to join the "Arduino is wrong" team. I also can't coax Excel into the former camp, but that doesn't mean that it can't be done because I found several examples of how to surface that base 2/base 10 mismatch, e.g. (43.1 - 43.2) + 1.

My apologies to the folks who came here to read about Pd

Edit: Both Java and Arduino display non-zero digits past the 7th digit when 0.1 is stored as a single-precision float, so I find it hard to believe that there's special-purpose code to suppress what I'm gonna refer to from now on as "SuperCollider panic"

@jameslo said:

@ddw_music This doesn't invalidate your larger point, but RE double precision floating point on Arduino, that reference is needs updating.

Ok.

For fun I tested c# (which agrees with SC and Pd64) and Java (which agrees with Arduino) so I'm not quite ready to join the "Arduino is wrong" team.

At the end of the day, 0.1 stored as any precision binary fraction doesn't actually equal 0.1, because the denominator of 1/10 includes a prime factor (5) that is not a prime factor of the base (2). If you ask for a decimal string for this imperfect binary representation and you ask for more (decimal) digits than are actually stored, then the trailing digits are by definition fake. They're not real.

"I find it hard to believe that there's special-purpose code to suppress..." but that is exactly what it is: the float-to-string function is supplying junk data, in a way that gives you an illusion of precision. Those zeros (the ones past the precision limit) are all fake. They don't exist in the binary number, so they must be manufactured by the "-to-string" function.

The standard C library way has the advantage of reminding the user that the trailing digits are garbage.

hjh

@ddw_music So in the case of c#, Pd64 and SC, are the non-zero numbers past the precision limit real?