Oppps I forgot the last section of David's posting. On Saturday 03 July 2004 16:54,David Abrahams <dave@boost-consulting.com>
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.
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.
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!
For the perspective of building further Linear Algebra algorithms it would not be too hard to use the syntax sufficiently portably so that a future MTL with expression templates could not be used interchangeably.
We have some problems with the syntax too, as you can see from the above. That said, if the design of MTL makes sparing use of members and instead relies on free functions, you should be able to make uBlas syntax adapters ;-)
Can't fault the logic here :-) All the best, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________
Michael Stevens <Michael.Stevens@epost.de> 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@boost-consulting.com>
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
participants (2)
-
David Abrahams -
Michael Stevens