Re: [boost] Re: Boost Mathematicians

From: Ralf W. Grosse-Kunstleve (rwgk_at_[hidden])
Date: 2004-07-04 17:48:43

--- David Abrahams <dave_at_[hidden]> wrote:
> Sorry, the "l" was a typo.  I meant Return Value Optimization, where
> values can be returned from functions without actually invoking the
> copy ctor.

That would be a cool thing to have, but searching for "RVO" and "Return Value
Optimization" in the C++ ISO standard didn't produce any hits. As long as it
isn't written down in the standard it is impractical for us (as scientific
application developers) to count on it.

> >> I guess you haven't read the MTL concept breakdown:
> >
> > Right. When I started with my array library (two years ago) it was clear
> that
> > MTL is too specialized for my purposes.
> >
> >>   - Shape
> >>   - Storage (I think this is what you're calling memory management)
> >>   - Orientation (row-major, column-major, diagonal-major...)
> >
> > Is "Orientation" a specialization of "Shape". Couldn't both be viewed as
> > "Indexing models?"
> 
> No, shape is separate.  No point in me trying to explain here when
> you can google for a good explanation from the MTL authors, though ;-)

I looked and in my mind Orientation only makes sense given a Shape, and even
Storage is only concerned with indexing! So I still believe Orientation is a
specialization of Shape. :-) And I cannot find the equivalent of my
"MemoryModel" concept (stack, heap, etc.) at all. "dense , banded, packed,
banded_view," etc., that's all just concerned with indexing.

Googling for "heap stack" at the MTL site didn't turn up a hit. So that
fundamental property of an array seems to be magically abstracted away.

> Whatever you like.  There will be well-formed concepts, so you can
> build any storage policy you like if it isn't directly supplied.

If that means I can choose between "heap" and "stack", "heap shared", etc. I am
excited.

> >> > 4. Array algebras (unary and binary operators, functions) are a third
> >> >    property that is ideally separated from memory models and, if
> >> >    applicable, indexing models. This could lead to:
> 
> HilbertSpace, BanachSpace, VectorSpace, LinearAlgebra, RModule, Field,
> Ring, AbelianGroup, LinearOperator, TransposableLinearOperator were
> the algebraic concepts we had in mind.  I don't think these things
> should neccessarily be part of the array type though.

My hope was that you'd cleanly separate MemoryModel from the rest of matrix
properties, and that the general framework is reusable for other array types,
i.e. n-dim arrays.

> > Does my generic array design look too daunting? 
> 
> Not neccessarily... but I doubt I'm going to implement your design.
> We have specific needs ;-).

Right now it seems to me that MTL matrices have a specific memory model
hardwired in (e.g. I see reference-counted std::vectors). That makes the
library a lot less interesting to me. Most of our matrices are small (3x3,
sometimes 9x12, in that ballpark). A heap based array type is therefore of
little interest. If "heap" or "stack" are not template parameters in some form
the whole matrix algebra code has to be replicated. That's not very generic.

> >> The aim is to make the library smart enough to do those optimizations
> >> correctly so you don't have to do it by hand.
> >
> > A case of "premature optimization?" 
> 
> No, one of the main _goals_ of this project (from a CS/research
> point-of-view) is to demonstrate that it can be done.

Can't argue with that. Only that this is not what I as a scientific application
developer am interested in. :-)

> Of course it is.  If you're taking a performance hit of about two
> orders of magnitude in your linear algebra code,

No, of course that's all happening in C++.

> I'll have to take your word for it.  It seems to me that if you can
> skip the brute force work in Python you can do it in C++, too.

Sure, I could even do in in machine language... if only I'd live long enough.
Python is very good at getting high-level bookkeeping done with relatively
little effort compared to C++. This makes it practical to accumulate the
knowledge that is required to selectively skip brute force number crunching
work. It doesn't mean I do everything in Python. Thanks heaven we have
Boost.Python and I can quickly farm out the number crunching stuff to C++.

Ralf

        
                
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail