From: rgarcia1771 (garcia_at_[hidden])
Date: 2002-01-07 15:36:46
--- In boost_at_y..., "Gary Powell" <powellg_at_a...> wrote:
> After a quick look at the code, I'm not seeing the full suite of
> operators, that libraries like MTL and others have. (Expression
> stuff.) Is this because multi-array is designed for a different set
First, bear in mind that there is a difference between a general
n-dimensional array library and a linear algebra library. While a
linear algebra library will tend to use two dimensional matrices to
represent linear transformations, some algorithms can make use of
matrix-free representations, where the matrix form of the
transformation never exists. In addition, operation semantics
(specifically operator*()) can differ depending on use.
multi_array is primarily a multi-dimensional container
type library that interoperates with the standard library containers
and algorithms. In addition it supplies core functionality (namely,
view creation and storage ordering) necessary for numerical
applications and extensions. The library IS intended to be used for
but operators should be layered atop what I am proposing.
I agree that the relationship between multi_array's types and the
matrix representations in ublas and MTL should be more clearly
> While the runtime speed may be a problem (C array vs multi-array)
> the chances of future compilers being able to generate more optimal
> My past experience has been that speed is everything but of course
> with lots of implementation bugs that could have been avoided if we
> strongly typed multi array to work with. Hence my dilemma.
I am investigating the performance implications of the
library and its design. Several others have been doing this
as well (which I very much appreciate). In some of my early
experiments, KCC was able to optimize away the abstraction layer
for operator(). I verified this by analyzing the C code generated.
I have added more features since then, so more experiments are needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk