Re: [boost] Re: Boost Mathematicians

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-05 13:45:24

Toon Knapen <toon.knapen_at_[hidden]> writes:

> I think Dave's evaluation of uBlas should be closely looked at and we 
> should address the issues mentioned. So I would like to comment so that 
> we can further these isues and really tackle these problems.

[small request: please leave a blank line between quoted text and
your replies.  I had to edit this one manually]

>
> David Abrahams wrote:
>
>> Jeremy and I have just completed a re-evaluation of uBlas based on
>> what's in uBlas' own CVS repository, having not discovered that until
>> recently (you should have that info on uBlas' Boost page!)  We have
>> some major complaints with uBlas' design.  The list is long, and the
>> issues run deep enough that we don't believe that uBlas is a suitable
>> foundation for the work we want to do.
>
> I however regret that you never provided your feedback before.

I didn't have the time at the time ;-).  I will note that Jeremy tried
to make the points about generic programming with the library's
original authors and they just didn't seem to "get it".

>> Here is a partial list of things we take issue with:
>> 
>> Interface Design
>> ----------------
>> 
>> * Not grounded in Generic Programming.  The concept taxonomies, to the
>>   extent they exist, are weak, and poorly/incorrectly documented.
>>   Aspects of the design that should be generic are not (e.g. only
>>   certain storage containers are supported, rather than supplying
>>   storage concept requirements).  No linear algebra concepts (vector
>>   space, field, etc.)  The library is so out-of-conformance with our
>>   expectations for Generic Programming that this one item by itself
>>   is probably enough to make it unsuitable for us.
>
> The problem regarding documentation regularly comes up on the ml. Some 
> people started with an alternative documentation for uBlas. Maybe it's 
> time to merge and rework all uBlas documentation. And indeed 
> documentation is crucial for developing generic concepts.

This isn't just about the documentation.  Implementations founded on
this kind of un-rigorous specification are almost certainly not
actually generic.  Combined with the other serious points we've
raised, it begins to look like a complete rewrite would be needed.

>> 
>> * Redundant specification of element type in matrix/vector storage.
>
> Could you elaborate ?

When you build a matrix type, you pass it a storage parameter that
also has knowledge of the matrix element type, and they probably (lack
of rigor in the docs don't make it very certain) have to match.  A
small issue.

>> * size1 and size2 should be named num_rows and num_columns or
>>   something memnonic
>
> This is just a matter of documentation. 

Disagree.

> AFAIK there is no accepted concept that demands 'num_rows' and
> 'num_columns'. The '1' and '2' refer to the first and second index
> which is also a nice convention IMO.

These are indexing rows and columns of the matrix, so they should say
so.  In some ways this is an aesthetic issue, but there are some
objective arguments that the current design is more confusing.  It's
possible to interpret "first index" various ways, considering the
possibility of row-major and column-major indexing.

>> * iterator1 and iterator2 should be named column_iterator and
>>   row_iterator or something memnonic.
>
> same as above.

Indeed ;-)

>> * prod should be named operator*; this is a linear algebra library
>>   after all.
>
> This also came up a few times and we never agreed how users could 
> clearly distinguish the product and the element-product
> so there was decided to use more explicit function-names.

What is an element-product?

> But the most important thing about operator-overloading is being
> able to use generic algorithms that exploit the given operator. 

No, that's the most important thing about generic programming (and
maybe function overloading).  The most important thing about operator
overloading is terse, recognizable expressivity.

> Not having operator* AFAIK never prohibited the reuse of generic LA
> algorithms.

IIUC, the set of NxN matrices forms a Ring, as does the set of real
numbers.  You should be able to use the same multiplication operator
to implement any computation that works on Rings.

>> * begin() and end() should never violate O(1) complexity expectations.
>
> That would indeed be ideal but why exactly do you insist on O(1) complexity.

Because of the expectation created by the standard.  Certainly O(N)
is way too much.

>> * insert(i,x) and erase(i) names used inconsistently with standard library.
>
> agreed. Again this could be solved by generating proper documentation 
> that is also inline with the documentation of the standard library.

Disagree.  It's an aesthetic/understandability issue that can't be
completely fixed with documentation.

>> * The slice interface is wrong; stride should come last and be
>>   optional; 2nd argument should be end and not size; then a separate
>>   range interface could be eliminated.
>
> I'm not convinced slice and range could be united. A range is a special 
> case that can more easily optimised compared to the slice implementation.

Maybe so.  The interface to slice is still suboptimal.

>> * Should use enable_if instead of CRTP to implement operators. uBLAS
>>   avoids the ambiguity problem by only using operator* for
>>   vector-scalar, matrix-scalar ops, but that's only a partial
>>   solution.  Its expressions can't interact with objects from other
>>   libraries (e.g. multi-array) because they require the intrusive CRTP
>>   base class.
>
> True but operator* between uBlas classes and multi_arrays are used very 
> frequently.

I must be misunderstanding something then.  Maybe you get away with it
because you've used prod() instead of operator* for matrix
multiplication.  How about operator+?

>> Testing
>> -------
>> * There should be a readme describing the organization of the tests.
>
> Indeed but this is a problem that can be solved (but must be dealed with)
>> 
>> * Tests should not print stuff that must be manually inspected for
                                       ^^^^
>>   correctness.
>
> Does it really bother you ?

Absolutely, for the reasons you agree with below.

>> * Test programs should instead either complete successfully
>>   (with exit code 0) or not (and print why it failed).
>
> agreed.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com