> Which you have to call no matter what.

No you don't, there is always another way to write the code. That's my entire
point. If people have to think more when performing an operation which is more
complex than a simple "+" then hopefully they might some way to do something
simpler.

That is the nature of optimisation, doing the same things in a different way.

> Just be aware of what you're adding. It's no harder than keeping track
> of a bunch of methods named add(), mult(), etc, and the code is much
> easier to read.

The standards we use would be more like matrixAdd(), vectorAdd(), etc. That way
it is easier to keep track of because you are using different function names
according to what the back end is doing. This means you can search for them in
the code, which is a very useful feature.

> How is this so? If you need to add two matrices, you need to add two
> matrices.

Do you? What if you're adding two vectors? What if you're adding two vectors
before computing a dot product with another vector? it may be possible to do
this more efficiently by computing the dot product with each of the vectors and
then adding the results.

Code is malliable, nothing needs to be written a certain way. Our aim is to
write it in a more efficient way, and to write it in a way that makes it easier
to optimise later.

> > Heck, if were even remotely
> > feasible we'd write everything in assembler...
>
> No...then you run into the "can't see the forest for the trees" problem.

Uh, I did say "if it were remotely feasible". Obviously it isn't for the reason
you state there. However there is such a thing as too high level for any given
application, and the consensus amongst people I've worked with is that operator
overloading is a little too high level for the kind of code we write.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message