@Glop-Glop I'd be lying if I said I understood your question or your patch, but if I were an LLM I'd answer you this way:
Untitled-1.pd
because your original post contained "[random 6]" and "lists" and the patch you posted contained an array with 16 elements, [16( -> [until], and [t b b b]. And because for layout I was trained on @oid's patches.

Here's a patch that displays floats to 8 significant digits and finds the range of such numbers that have the same value. I didn't know how to handle zero so I just ignored it. I'm sure my algorithm for finding the range is naive, overly complicated, and buggy so you'd be wise to check the values before using them for anything important.
float inspector.pd

Note that in this snapshot, the truncated number that Pd displays is not in the range of equivalent values, so the value of this number will change if you, for instance, enter all 8 digits into a message, save the patch, and then reload the patch. This will be true even though the displayed value does not change.

@whale-av WOW!!! THOSE ARE MAGNIFICENT!!! I used to get teased at work for using an HP50g, but if I had one of those I could've told everyone off.

One of the search results suggested running a service in Java that exposes the BigDecimal API and all the operations (e.g. over OSC), so your idea isn't so far off, although the Arduino you'd have to use to implement the interface would probably have more computing power than both those calculators combined

The Java library has an object called BigDecimal that implements arbitrary precision decimal numbers and the arithmetic for them. It allows you to do currency calculations without having to worry about the rounding issues inherent in floating point. c# has something similar but it has a smaller digit limit, I guess to allow it to run natively. Do you know of an external that does something like that for Pd?

Hey @alexandros, did you look any further into why [expr ceil($f1)] isn't working on your installation? That seems so odd to me and I'm really curious about it.

@ddw_music I think you mean %.8g because you have to count the leading '1' in [makefilename].

Assuming I'm right, this is unfortunately making me feel more strongly about the shortcomings of Pd's number box truncation because 0.1 displays as 0.1 under [makefilename %.8g] whereas the problem in my original post displays as 255.00002. At the very least there ought to be a precision setting in each number box's properties. Like too many things in Pd, it feels perverse to have to tell a new user that in order to display a unique character sequence for a number, you have to turn it into a filename And gosh, it looks like SC has several numeric datatypes, ways to cast between them, and multiple ways to display each. How profligate!

@whale-av Your titles made me laugh anyway. If it wasn't my thread I would've suggested "horseshoes, hand grenades, and single precision floating point." Or now, maybe "Who is number 0.1? You are number 255"

I was a software engineer for several life sciences and financial services companies and don't remember anything like 255 != 255, but we also had the luxury of more than one numeric datatype and a lot of formatting options.

@ddw_music said:

%.7g isn't enough, but %.8g seems to catch it.

That Fortran discussion I linked to presented the number 1.00000048 as an example of a 9 digit decimal that has a SPFP value that's not representable in 8 decimal digits, but it appears to me that 1.0000005 works fine. How would you prove that 8 digits is sufficient for all SPFP numbers?

@dreamer Finally! My intention was to solicit a whole bunch of funny titles and to make the thread playful, but I've obviously failed Yours wins unless someone posts something funny.

@ddw_music Thanks again. If you wanted to see that truncated noisy digit (say, to debug a patch), how would you go about displaying it? The goal is to avoid the situation above where two floats have the same display but don't equal each other. Would [makefilename $.7g] suffice? Or would it have to be .8 or .9 as some argue in this discussion https://fortran-lang.discourse.group/t/how-many-significant-decimal-digits-for-real-single-precision/2287 And for all cases 7 8 or 9, it would mean that there could be different displays of floats that actually equal each other, correct?