Re: [boost] Re: multi_array resize?

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2003-10-30 03:22:51

Hi Ron,

[...]

> >I've recently started to write ublas adaptors for multi_array and its
views.
> >A couple of observations/questions:
> >
> >- it probably would be a bit easier to adapt multi_array if it would be
> >default constructible
> >
> Yes.  As it happens, I added support for a default-constructible
> multi_array at the same time as I added the resize operation.  Resizing
> and default construction seemed tied together.

Great news!

> >- I don't like the necessity very much to 'typedef' multi_array's range
> >- how does one distinguish multi_arrays from multi_array_views
generically?
> >
> Currently there is no mechanism for doing so.  When is this
> functionality useful?

Multi_array's copy constructor performs a deep copy. So to hold a reference
to it in ublas' expression template machinery I'll probably have to use some
kind of reference_wrapper (I believe multi_array_ref is the way to go). This
indirection shouldn't be necessary if we're going to adapt a
multi_array_view (but it probably won't hurt too much).

I'll check this.

> >And one from Kresimir Fresl:
> >- how does one distinguish C storage and Fortran storage layout
generically?
> >
> Since the storage layout is not part of an array's type,

It is for ublas' containers.

> you cannot
> distinguish the two generically (assuming that by generically you mean
> "at compile time").

Yep.

> The multi_array has a storage_order member function
> that returns the storage order object.  This can be used at runtime to
> determine the storage order of an array, though it is expressed in a
> more general form than C or Fortran storage order.

OK, so the user probably has to explicitely specify row major or column
major order when describing the type of a multi_array::matrix_adaptor (and
this could differ from multi_array's storage order). Don't know if that's
acceptable.

> Hope this helps,

Thanks very much,
Joerg