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.

@jameslo said:

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

It's a minority case, I guess...? I'm willing to bet that in most cases, a user who summed up 0.1 ten times wants to see "1" and not "1.00001".

And gosh, it looks like SC has several numeric datatypes, ways to cast between them, and multiple ways to display each. How profligate!

SC has 32-bit int (Integer) and 64-bit float (Float, not Double) in the language side, and the audio side runs on 32-bit floats like Pd audio does. 64-bit floats can be chopped down to 32 bits, but the value is stored as an int and you can't do 32-bit float math on it. But, converting a couple of such ints to double (Float.from32bits) and doing math on them should be (pretty much) the same as single-precision math, except maybe a bit of noise in the LSB.

hjh

@jameslo I just combined all your patches into one and they all behave like yours! I don't know what was going on earlier, perhaps a typo in [expr]? But I guess it wouldn't have been created. Now the numbers are toggling between 255 and 256 and 0 and 1.5258e-05, like your screenshots.