Re: Multi Array Review vs. Budd

From: rgarcia1771 (garcia_at_[hidden])
Date: 2002-01-09 16:03:50

Hi Larrym

--- In boost_at_y..., Larry Evans <jcampbell3_at_p...> wrote:
> Larry Evans wrote:
> 
> >
> > Could someone compare this method for accessing subarrays with the
one in:
> >
> >       _An APL Compiler_
> >      Timothy Budd
> >       Springer-Verlag(1988)
> >
I'm trying to locate a copy of this book, but so far I'm coming up
empty handed. Perhaps some of the ideas in this book could lead to
optimizations in multi_array's implementation.  If they do not affect
the interface, though, they need not be implemented prior to
multi_array's acceptance.  I'm very open to optimizations, so long as
they don't require all users be aware of them.

> 
> The following is a short comparison between Budd's book and
> multi_array:

Thanks for the info!

>     t[i] == ?
> 
>   The ? above indicates I couldn not find any corresponding
>   multi_array data.  t[i] in Budd's book is used when an dimension
(or
>   axis in apl nomenclature) is "reversed", i.e. index 0 actually
>   corresponds to s[i]-1.  However, the base.hpp:346 line defines
>   calculate_descending_dimension_offset, which looks like it does
>   something related, but I'm not sure.

Given your description of t[i], I would say that your assessment is
correct. You can create a [const_]multi_array[_ref] that has
descending dimensions and a customized memory layout by passing a
boost::general_storage_order to the constructor.  

> I would recommend NOT accepting into boost until some methods for
> reversing axes and other methods for transposing axes are provided.
> In particular, it's unclear from the code how to get a false entry
> into ascending_. 

This functionality exists in the library.  I am updating the
documentation to reflect comments made here.  Memory layout is one
area I'm targeting for extended coverage.

> I think there's a concern about management of the "configuration"
of the
> array.  For example, in base.hpp:129, the call to Reference seems to
> pass pointers to the extents and strides.  I assume, then that
> Reference is a multi_array_ref, but then multi_array_ref doesn't own
> the extents or strides either.  Right?  On the other hand, some
other
> operations may require the result to copy all or part of the
> "configuration".  For example, wouldn't slicing the array require
> this?
Each [const_]multi_array[_ref] owns its own extents and strides
information.  In addition, views generate and own their own extents
and strides as well.  subarrays, on the other hand, inherit and refer
to the strides and extents of the parent array type.  Thus, calling
operator[] on a multi_array will construct a subarray that points to
the parent's extents and strides.

Cheers,

Ron