From: David Abrahams (dave_at_[hidden])
Date: 2004-07-05 13:53:13
Michael Stevens <Michael.Stevens_at_[hidden]> writes:
[small request: please leave a blank line between quoted text and
your replies. I had to edit this one manually]
> Oppps I forgot the last section of David's posting.
> On Saturday 03 July 2004 16:54,David Abrahams
>> > Other then the many forms of blocking (other then banded) uBLAS
>> > supports all these in its design.
>> I believe that a design with really good support for blocking can't be
>> easily grafted onto an existing design that doesn't have it.
> Now I understand. Blocking in the context of evaluation rather then
> sparsity/ shape. Yes this is a good point. Blocking evaluation
> requires significant contribution from the Expression Template
> mechanism that is not present in uBLAS.
I think there are other serious problems in the uBlas ET mechanism.
For example, it is a rather naive implementation where each node
"knows" how to evaluate itself, which inevitably means that in some
expressions decisions get made too early -- sometimes it's better to
introduce a temporary depending on what will happen to the result of
a given computation. I think yAB might be an example, but I don't
remember and I'll leave it up to Jeremy to correct me.
>> > Other then the lack of ET in the current MTL the big difference
>> > between the two libraries is the definition of iterators. Neither
>> > design seems to be perfect with regard to efficiency.
>> No, and I have some ideas for addressing that.
> A improved iterator concept that allows succinct coding and runtime
> efficiency would be a big step forward.
I don't think we need a new iterator concept. Actually I have a hunch
it can be done with standard iterators, but I won't know until I've
conducted some efficiency experiments on various compilers.
>> > Since uBLAS is already in Boost and has a well established and
>> > clean user syntax it would seem strange to ignore it.
>> Yeah, I stopped ignoring it long enough to determine for sure that we
>> should probably ignore it :(.
> No sure what to say here!
Sorry; that wasn't the answer I wanted to give you :(.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk