Re: OONSTD: objections
E. Robert Tisdale (edwin2@gte.net)
Wed, 09 Sep 1998 00:32:00 +0000
Andrew Lumsdaine wrote:
> In our last exciting episode "E. Robert Tisdale" wrote:
>
>> Is there something about your approach that requires a design like this?
>
> Number one: performance. Using C++ only,
> MTL achieves or exceeds the performance of vendor tuned BLAS.
>
> Number two: genericity. Like MTL or not, MTL has an astonishing set
> of functionality with only a small amount of code. The functionality
> is combinatorial but the work required for implementation is only additive.
>
> Number three: MTL is aimed more at library writers than programmers
> who want a C++ library that looks like matlab. One could, for example,
> easily layer a library with a semantically pleasing interface on top of MTL
> (and we have done preliminary implementations of such libraries).
> We wanted to get the guts right first for a number of reasons.
>
> While having a library that provides a matlab like interface to the
> programmer always seem to be appealing, the usefulness of such an
> interface is over-rated, in my opinion -- at least to library developers.
> To "application programmers" this might not necessarily be the case,
> but then matlab itself becomes an attractive alternative,
> especially with the matlab->C++ translators available.
>
> There have been any number of vector and matrix class libraries developed
> and released (and I have developed and released one or two such libraries)
> and yet no one ever gets very excited about any of them.
> In trying to understand why this has happened
> I compared what has been happening in the linear algebra domain
> with what has happened in the "foundation class" domain.
>
> As with linear algebra class libraries, numerous foundation class libraries
> have been developed and promoted (many more than in the linear algebra case,
in fact).
> Yet, only one really prospered and was embraced by the C++ community -- the
STL.
> IMHO, the reason that STL prospered was because it was in fact an
architectural specification,
> of how a container should behave, how an algorithm should interface to a
container
> (through the use of iterators) and so forth.
> Although the actual concrete components of STL
> are considered by many to be the true success of STL,
> I consider the contribution of STL to be much more profound --
> namely the elucidation of foundation class behavior
> rather than the specification of a particular class library.
>
> This was the basic idea behind MTL. MTL presents
> a picture of linear algebra objects as being compositionally constructed
> from certain types of containers (i.e., containers with certain
specifications)
> and adapters (in particular, one and two dimensional containers for storage,
> adapter classes for orientation, shape, and the like).
> Given this presentation of linear algebra objects and the corresponding
interfaces,
> linear algebra algorithms can be written generically.
Please correct me if I am wrong
but it appears to me that you simply want to standardize at a lower level than
SVMT.
Instead of using a standard library like SVMT. application programmers would
develop
their own libraries which they would port along with the application to other
platforms
just as so many application programmers seem to be doing right now
but library development would be much easier because they would use MTL.
I think this scenario of use is just fine
but I don't believe most application programmers want to write their own
libraries.
Thousands of people use Matlab and similar commercial packages.
Thousands of people have downloaded "The C++ Matrix class" library
since I first made it available on the internet almost a decade ago.
I'm sure Robert Davies has distributed thousands of copies of newmat.
I get electronic mail from people all over the planet who use these libraries.
Some of these people just want tips on how to write their own library
but most just want a library they can use to get something done.
I think most application programmers really want a Matlab like interface.
It is more concise, and requires less documentation to explain than
the more primitive BLAS like interface.
Unfortunately, Matlab appears to be fatally flawed.
There are overheads embedded in basic operations
which the Matlab compiler cannot optimize away
and the application programmer is often obliged
to re-implement critical sections of code in C or C++.
When I proposed the C++ SVMT class library standard,
I was very careful not to specify how it was to be implemented.
I believe that the implementation details should be left up to
the library developer. I don't think MTL changes this.
SVMT and MTL appear to be independent of each other.
I think we all understand genericity and the efficiency of templates
but I don't think we will get as much mileage out of them as the STL.
Part of the reason is that Vector, Matrix, Tensor, etc. classes aren't
really containers for any type. The Standard Numerical Library is,
by definition, pretty much restricted to a few numerical types
which have few methods in common so most of the specification
standardizes specializations for each of these numerical types.
Bob Tisdale <edwin2@gte.net>