It's more than just matrices, though. For instance, I have a little library that propagates uncertainty for me. Without operator overloading, I'm back to descending into the rpn hole from my example.
Another poster pointed out unit analysis. I've done this before with custom types that keep track of the units on measurements.
Since you mentioned parallelization, that's another fun toy I've played with. By overloading the operators for an object that defines a snippet of OpenCL code, it's possible to push these snippets through pre-existing functions and have it return a final OpenCL function. You then call that returned function on your arrays of data to run everything through your GPU with just three lines of code changes from the sequential.
Operator overloading is more than just adding matrices. It's a powerful technique that comes in handy almost any time that you're working heavily with numerical data. Of course, it's also dangerous as hell in the wrong hands. The code for the OpenCL example was actually some pretty terrible code that did extremely non-intuitive things during value comparisons.
Operator overloading can certainly do good things. Not going to argue with you there. Though, in the case of units, you can actually go a long way with that (http://play.golang.org/p/iCqB2euJj8). It's not perfect, you have to do some function calls to multiply units of differing type correctly, but you do gain all the proper compile-time safety, and you don't need to do all sorts of method calls.
What are you doing with uncertainty that you can do operator overloading with? You usually want to do Bayes rule with probabilities, but that gets intractable fast.
Another poster pointed out unit analysis. I've done this before with custom types that keep track of the units on measurements.
Since you mentioned parallelization, that's another fun toy I've played with. By overloading the operators for an object that defines a snippet of OpenCL code, it's possible to push these snippets through pre-existing functions and have it return a final OpenCL function. You then call that returned function on your arrays of data to run everything through your GPU with just three lines of code changes from the sequential.
Operator overloading is more than just adding matrices. It's a powerful technique that comes in handy almost any time that you're working heavily with numerical data. Of course, it's also dangerous as hell in the wrong hands. The code for the OpenCL example was actually some pretty terrible code that did extremely non-intuitive things during value comparisons.