OON's most noble goal is to make life easy for the user. Which in
my view is synonymous with making the code look like mathematical
equations.
> 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).
Optimizing for A==C in A*B*C^T is probably not worth the cost to
detect this case (I don't see a way to detect it at compile-time).
Usually mathematicians don't bother to use a special syntax for
this idiom. It is an idiom however and it only has two arguments
as such. Therefore the operation should be handled by a dedicated
operator, e.g. M.transformed_by(J);
For our library a zillion equals one here, the transpose is just a
tweaked reference to J. I don't to optimize code like this unless
I know it's a bottleneck. We don't use exactly block sparse
matrices but have a ``blocked unit matrix'' class
(looks like 100100100...
010010010...
001001001..., how would you call this? ).
The code looks the same and sure does take advantage of the types'
structure for any combination of the available types for J, M and
A.
> Now, some people (and even some oo books) will argue it's
> possible to generate efficient code for the first expression by
> doing some wacky lazy-evaluated expression objects and the like,
> or maybe by using some really stoked reference-counted matrix
> classes, but jeez, that's incredibly complicated compared to the
> second expression, and not likely to be as efficient.
Why would lazy evaluation be wacky? It may not be trivial to
implement, but the author will get a lot of satisfaction out of
doing it, and the users don't even see it. When you write a
specialized C-style function a la DoMyOperation(J,M,A), the best
way to do go about it will result in essentially the same machine
code that a good lazy eval scheme will produce. I haven't tested
this, but folks say that lazy eval comes to within a few percent of
hand-coded C efficiency.
And reference-counting is ``fat''? It allows for a very
mathematical look of your code -- you don't have to allocate
results beforehand -- and doesn't have a noticeable effect
on performance (unless you're dealing with 2 x 2 matrices).
Writing such a library takes some work. The point is that doing so
saves a lot of work in the long run, when there are enough users.
Mike Henderson <mhender@watson.ibm.com> wrote:
> ... main uses of OO languages and OO design in this field:
>
> 1) To write a better applications (toolkits, PSEs, ...),
> front-end to back-end.
This is hard to do with existing tools.
> 2) To provide better reusable tools.
This we should do, to make the above easier.
Rainer
______________________________________________________________________________
Rainer Blome http://www.physik3.gwdg.de/~rainer/
Drittes Physikalisches Institut
Buergerstr.42, 37073 Goettingen, Germany Tel:(+49)551-39-77-31
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST