# question on BASICally conversion

I’d like to invite any BASICally and µMatrix user to assist me in resolving the mystery.

Manually moving CvY knob on uMatrix I receive a sequence of voltages on the CV output. They are also shown on the left TTY module and the values are as expected.

I created a small BASICally script to convert the values (-2.4, -2.5, etc.) to some other CVs. Interestingly BASICally skips two of the input voltages. In case of -3.1 input and -2.6 input BASICally doesn’t convert anything. TTY on the right shows the lack of ‘1’ and ‘6’.

Why? Is this some rounding error?

Demo BASICally with uMatrix.vcvs (4.0 KB)

Not sure if this is the issue, but in BASICally, I always take the absolute value of the difference between the value and what I am comparing to and check if that number is less than my “error” limit and if so treat them as equal. It is always difficult to check exact equality with floating point math.

1 Like

@k-chaffin is correct here. BASICally seamlessly ports the aggravation of dealing with floating point numbers into VCV Rack.

Changing:

``````if in1==cx[i] then
``````

to

``````if abs(in1-cx[i]) < 0.001 then
``````

Makes it work the way you want.

I’d be happy to replace my “a == b” test with a “abs(a-b) < epsilon” test, except that it appears that there is no one good value of epsilon.

But, sheesh, I’ll take suggestions on how to make this less confusing. BASIC is supposed to be easy for people who don’t care about stuff like this.

(Also, happy to see TTY being used as a debugging aid. Do note that setting RATE to 539 ms (as you’ve done here), means that it’s polling the V1 and V2 ports less than twice a second. Even a slow knob movement night exceed that.)

2 Likes

The author of that page does go on to suggest the following:

``````bool floatCompare(float f1, float f2) const
{
static constexpr auto epsilon = 1.0e-05f;
if (qAbs(f1 - f2) <= epsilon)
return true;
return qAbs(f1 - f2) <= epsilon * qMax(qAbs(f1), qAbs(f2));
}
``````

In other words, scaling epsilon to the size of the numbers being compared. Seems decidedly better than what I’m doing now.

1 Like

It would be pretty confusing for programmers if you “redefined” floating point equality to mean something else, even if the current definition can be confusing.

If you wanted to add some helper function, that’s not as problematic.

btw, floating point equability does “work”, or course, for some numbers. In particular many integers can be exactly represented in IEEE floating point, so equality does work for those cases. An awful lot of JavaScript code relies in this.