weird poop.pd

I can't see anything wrong with it. The result before [expr] is 255 when using both 1 and 44.1 for the first division and the multiplication. Isn't this what should be expected?

@alexandros After you do those 3 clicks, it computes the ceil(255) to be 256. On the first click it returned 255. I think it's an unfortunate side effect of the limited ability of floats to represent decimals together with how number boxes truncate, and so that second 255 is really a tiny bit larger.

On my machine, no matter how many times I switch between 1 and 44.1, I always get 0 after [expr].

@alexandros For modf or ceil?

@jameslo for ceil. I only tried the patch of the screenshot in the first post.

@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

When performing division of rational numbers, the result will be exact if the denominator factors out such that all factors are a power of a factor of the numeric base. We're used to decimal, so those factors are 2 and 5. 20 = 2•2•5 so it's ok; 27 = 3•3•3 so we know this will be a repeating fraction (since 3 is not a factor of 10).

Floating point numbers in computers are base 2, so, for non-repeating division, the denominator must be a power of 2.

First you have [/ 1] -- 1 = 2^0 so, ok.

Then you have [/ 64] -- 64 = 2^6 so, ok.

When you introduce division by 44.1, then the denominator includes two 3s and two 7s (plus 2^-1 and 5^-1). These aren't powers of 2, so the fraction will be infinite, and rounding it off to the available precision is an approximation. Multiplying again doesn't restore the precision.

Like, 2/3 = 0.66666...7. Let's pick an arbitrary precision, say, 4 digits. 2/3 = 0.6667 (or, the floating point way, 6.667•10^(-1)). Now you multiply this back by 3 and you get 2.0001 -- there's your "higher than." This must also get rounded off, but at least it shows that inaccuracy when scaled up can eventually become visible.

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.)

hjh

@jameslo The patch you provided indeed shows the bug. When clicking 44.1 the number on the bottom is 0. When clicking on 1 or 48, it's 1. But @ddw_music gave a very good explanation of why this is happening.

@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?