> I guess I'm thinking pretty selfishly here, but the problems I run into each
> day are how to convert an equation like A = J*M*J^T into efficient computer
> code. The naive approach in C++ is:
>
> matrix A = J * M * Transpose(J);
>
> Which creates a zillion temporary matrices and doesn't take advantage of any
> of the structure (M is diagonal and J is block sparse). If, to get
> performance, I'm forced to write:
>
> DoMyOperation(J,M,A); // computes A = J*M*J^T, M diagonal, J block sparse
>
> the what did I gain from going to an oo language (in this section of the
> program)?
The comparison is not quite fair: your "procedural" line assumes the
existence of a function written explicitly for the problem at hand,
whereas you expect a general solution from the OO approach. If you
are willing to accept an equally specialized OO solution, nothing
prevents you from writing three different matrix classes for the
special structures of J and M and implement a multiplication operator
for each combination you need.
OOP is just a method of structuring code, no magic to prevent writing
it. If efficiency demands a special algorithm for each combination
of a hundred different matrix storage schemes, then these have to
be written one by one. The best you can expect from OOP is to hide
this mess from the user.
-- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais -------------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST