Boost logo

Boost :

From: rgarcia1771 (garcia_at_[hidden])
Date: 2002-01-07 15:36:46


Hi Gary,

--- 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
template
> stuff.) Is this because multi-array is designed for a different set
of
> problems?

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
numeric purposes,
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
defined.

> While the runtime speed may be a problem (C array vs multi-array)
what are
> the chances of future compilers being able to generate more optimal
code?
> My past experience has been that speed is everything but of course
that came
> with lots of implementation bugs that could have been avoided if we
had a
> 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.
ron


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk