For pd64, I would just remove the precision (.6) and go normal %g, leaving it up to the system. I don't see the need for making it configurable globally or on a per-object basis, which is adding more complexity. Keep the "data pure" so people can clip, filter, apply an epsilon check for small numbers, etc. ;)
If you want to show *everything* losslessly, apparently %.9g for float and %.17g for double, although that seems overdone to me. There are also the FLT_DECIMAL_DIG and DBL_DECIMAL_DIG defines in float.h for this. :)
Ref: https://stackoverflow.com/a/21162120
I prefer the simplicity of letting %g of just do it's thing in this case, and keep %.6g as it is for pd32.
On Nov 26, 2024, at 2:20 AM, pd-dev-request@lists.iem.at wrote:
Message: 3Date: Mon, 25 Nov 2024 22:20:32 -0300From: Alexandre Torres Porres <porres@gmail.com>Subject: [PD-dev] Re: why nor increase the '%g' precision for pd64?To: Giulio Moro <giuliomoro@yahoo.it>Cc: pd-dev <pd-dev@lists.iem.at>Message-ID: <CAEAsFmg=F9zWi0970c83sP4dMYGoOF794w-5DbFTSVcUy0fiSA@mail.gmail.com>Content-Type: multipart/alternative; boundary="00000000000076eed00627c6a88b"The thing is that a higher precision in single precision will give you manyfloat imprecision errors and it's also annoying.I guess using %g is a good compromise for single precision in messages,objects (as arguments) and comments. Maybe being able to set with moreversatility would be nice in an object like [print], or as a new parameterfor the number boxes. Or I can try and create externals that deal with thisfor power users, I don't know...But at least a hardcoded higher precision makes sense in general for pd64.I don't know yet which one would be good and others here may know better.And I think that a highger precision by default would deal with your issueGiulio, right?cheers