What was zero is now -2.52621e-08 in float Parameters

General JUCE discussion
1

I’ve had some time away from JUCE & just come back have this strange zero issue. For example I have a large modulation matrix that used approximatelyEqual() to decide whether each output needed to be processed or not, which now fails & so it was processing all of them that are supposed to be zero.

I discovered that the parameter value via getRawParameterValue which should be zero is actually this small scientific value : -2.52621e-08. As a result my sliders are all showing that value and when double clicked to trigger the default value.

I pretty stumped as to why it’s happening, I’d upgraded to v8 and went back to 7 and it’s happening there too, so it must be something I’ve done locally I suppose. I’ll investigate older Time Machine versions tomorrow, but wondered if anyone had any ideas what could cause this?

The only thing that’s changed that I can think of is that I upgraded to an M4 Mini last week & so also Sequoia.

IMG_1666
IMG_16663264×1883 2.5 MB

2

I just tested a version from August and it’s doing exactly the same thing so it seems it must be to with Sequoia or the M4… I have no idea what to do about it.

Well I’ve set the precision on the display to correct it, but it’s concerning that it causes approximatelyEqual() to fail in the processor, I suppose I’ll just have to replace my usage of it with my own less precise check.

3

I’ve observed this behavior when I switched from an Intel Mac to an Apple Silicon Mac (in my case it was an M1).

4

Interesting! I was previously on an M1 and it was normal. If it’s down to architecture I wonder if that means it will behave differently on different machines in the compiled programs. I don’t think it’s a massive deal, but not being able to rely on JUCE approximatelyEqual() is a concern.

5

At some point our CI tests failed with similar “oddity”. We have our own “isclose” functions so we have tolerance.

It turned out some OS update changed Accelerate framework. When we reached Apple they said it’s fine since it’s within their (undocumented) “tolerance” range.

You can do try running under Rosetta which most likely match x86_64 so you can compare if there’s a change there. (I guess it’ll also be there since I’d expect some SIMD under the hood that ends up using Accelerate).

but not being able to rely on JUCE approximatelyEqual() is a concern.

Looking at the docs, JUCE’s approximatelyEqual does have tolerance argument (as I’d expect).
So for your use case (which we don’t know), you’ll might need bigger tolerance…

2 Likes
6

Thanks, that’s good to know!