Overloaded inbuilt operators causing maximum recursion errors

I am trying to do overloaded inbuilt operators, such as overloading == (eq) for A == B (or eq(A,B)).

I did this: In my working directory I created a new folder 'overloads' , within that directory created a folder @double, and then the function eq.m which is my overloaded function:

function [result] = eq(A,B)
if abs(A-B)<1e-12
result = 1;
else
result = 0;
end

This seems to work fine. The problem is I am getting weird behavior after creating this overloaded function. For example whenever I subtract two numbers in the command line, such as 4-5, or 2 - 3 (any numbers really), I get this error: "maximum recursion limit of 500 reached... etc'. Whenever I try to use any operators, even ones I have not overloaded, I get this weird behavior .

Any ideas?

[JMP Phillips]

It seems no one knows why recursion errors come up when overloading built-in functions.

[Walter Roberson]

What happened when you fixed your routine to return logicals?

[Guillaume]

@JMP, which version of matlab? I cannot reproduce in 2015b.

"It seems no one knows why recursion errors come up when overloading built-in functions" It's more that no one really care as it's not something you should do for built-in types.

[Walter Roberson]

So when someone said "In your code the double 0 and double 1 you returned would have had to have been compared against 0 by MATLAB in order to try to figure out whether the value you had returned was true or false" was that something other than an explanation for why the recursion errors were occurring?

[Adam]

Your code will also say two numbers with difference smaller than 1e-12 are equal even if those numbers themselves are of that order of magnitude and are percentage-wise very different, but I guess if you never work with small numbers and you are happy to accept any consequences of Matlab's algorithms also using your definition of equality that is 'ok'

[JMP Phillips]

Walter, if you mean that MATLAB's comparison routine involves some sort of recursion then that may explain it but I don't understand it.

Changing to logicals did not resolve the issue (was working yesterday, not today), so must be something else.

Additionally, when I try to open the function file from within matlab, it also gives a recursion error.

Anyway thanks for your answers much appreciated.

Answer 1

[Walter Roberson]

function [result] = eq(A,B)
  result = abs(A-B)<1e-12);
end

Notice this returns logical not double. In your code the double 0 and double 1 you returned would have had to have been compared against 0 by MATLAB in order to try to figure out whether the value you had returned was true or false.

I recommend, by the way, that you specifically comment how your code will deal with NaN and with vectors or arrays and with comparing values of different size()

I also recommend that you consider making the tolerance a relative tolerance based upon eps.

[Guillaume]

Well, I would recommend that you do not overload the equality operators (or any other standard operator) for numeric types. This looks like a misguided attempt at coping with floating point rounding errors but is more likely to lead to more problems than it solve.

Equality has a well defined meaning, you are going to break a lot of code if you change it. As you've found out, it's very easy to break seemingly unrelated code simply because these operators are used everywhere.

[Stephen23]

+1 "This looks like a misguided attempt at coping with floating point rounding errors"

[Walter Roberson]

I am of the opinion that sometimes our teaching role is best accomplished by giving the person exactly what they asked for, so that they can experience the inevitable disaster for themselves. Someone who has gotten as far as overriding operators for double probably isn't going to listen to our warnings and needs to watch their attempts crash until they are ready to listen again.

[Adam]

In addition to Guillaume's comment, Matlab uses its operators within many of its own other builtin functions so if you overload them you can easily end up with your overloaded function being called in all sorts of places you don't expect rather than just the ones you explicitly use yourself.

[Walter Roberson]

When you overload an existing class operator you are not making any explicit references, you are messing with ALL use of the operator (except for nested functions in the original implementation, those take local precedence.) Overloading is nearly unscoped.

But the poster did not ask us if this was a good idea, or ask us how to confine the effects to particular routines. The poster has already gone as far as to keep the power supply on while opening the cover of the No User Serviceable Parts section, and I am okay with them finding out experimentally what can go wrong.