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?

@ddw_music said:

The assumption that floating point math is exact is basically a good way to set yourself up for confusion or disappointment. (That is, this isn't Pd's fault -- it's IEEE 754.)

But what prevents Pd from displaying the inexact result, e.g. in the number box above [expr]? If the goal of patching is to make things more friendly for non-programmers, how is it helpful to hide it?

@alexandros Hmm, that's not good. The ceiling of 255 is definitely not zero and that's preventing you from seeing the thing I wanted to draw attention to. Here's another version for you to try: weird poop 2.pd

@alexandros For modf or ceil?

@porres I'm just looking for guidance on how to use it properly and what to expect from it. [cyclone/buffir~] states a limit in help, and [audiolab/pp.fft.partconv-st~] warned me that internal buffers had been exceeded. REAPER just silently ignores everything past 30 seconds.