[boost] Re: Matrix

From: Ronald Garcia (rgarcia4_at_[hidden])
Date: 2001-03-13 10:55:41

>>>>> "JL" == Jerome Lecomte <jlecomte_at_[hidden]> writes:

    JL> Walter wrote:
    >> I currently see the following points to discuss when developing
    >> a matrix library:
    >> 
    >> - support for mathematical notation
    JL> I agree this is the whole point (and maybe the only reason) to
    JL> have a C++ interface.

    >> - efficiency
    JL> That's where I don't quiet follow. Isn't the best way to
    JL> achieve Fortran speed, to call Fortran ??? I don't see the
    JL> point in pushing further the expression template trend
In order to get both mathematical notation and performance in C++, you
need to have expression templates.  The reason is that use of
operators leads to a  proliferation of temporaries as each
operator is called. 

    JL> ... This is a nice concept, and something to develop for the
    JL> future (when compilers better support export keyword) but
    JL> right now, I would support something along the line of
    JL> lapack++ (commercial by RogueWave) where the C++ is actually
    JL> just an interface to Fortran code.
I'm not quite sure what would be gained by the use of the export
keyword in this case.  Writing good libraries often involves pursuing
some hard work, but the expected benefit is that the library is then
easy to use practically (ie. with expected good performance) out of
the box.  That's one of the great benefits of the C++ standard
library.  

Another benefit of ditching Fortran is the possibility of a portable
tunable library.  I'd highly recommend taking a look at the MTL and
Jeremy Siek's M.S. thesis. Many of these issues have been considered
therein.

    >> -compatibility This is an interesting question: should a boost
    >> matrix library run under MSVC for example?
    JL> I wish so.
I'll second that. One of the great aspects of BOOST IMHO is it's
portability to as many compilers and platforms as reasonable,
including one of the most commonly used C++ compilers.

    JL> As far as boost is concerned, we could distribute the wrapper
    JL> as part of boost. I can understand though that it isn't nice
    JL> to distribute an half-finished product and request the user to
    JL> download additional material to make it work ...

I don't like the road this is going down.  I find it very sensible
that Boost.Python would require the availability of Python on an
architecture, but requiring Fortran and a Fortran library for a C++
library seems far less than ideal.  We can do much better than this.

ron