Boost logo

Boost :

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
> <dave_at_[hidden]>
>
>> > 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