🚀 go-pugleaf

>>>>> "MA" == Matt Austern <matt@godzilla.EECS.Berkeley.EDU> writes:
[...]
MA> Which reminds me: I've heard rumors that there are known problems with
MA> the current definition of valarrays, that they don't actually solve
MA> the aliasing problems that they were supposed to.  I know no details.
MA> Has anyone else heard anything of this sort, and, if so, can you
MA> provide any specific information?
[...]
Hmm, here is a summary of what I have seen.

During the public comment period (here in the US) I submitted a comment
and proposal arguing that any valarray implementation in C++ conforming to the
current DWP text (and not relying on specific compiler support) would
be very innefficient. The alternative I proposed was based on experience
with implementing portable but efficient numerical arrays; my original
proposal can be found in 
	ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray/Documents/ansirev.*
Implementations close to that proposalcan also be found there.
This proposal introduces the concept of `storage model' to relax the
type-requirements of valarray operators, e.g.:
	valarray<double> a(1000), b(1000);
	a+b; // Result is not necessarily of type valarray<double>;
	     // could be e.g. of type valarray<double, ArraySum<double> >.
Hence the new template is declared as:
	template<class T, class M = c_array> class valarray;
I also proposed a standard m_array model that would allow storage of 
numbers outside the C address-space (e.g., for distributed computing
purposes). Note that the storage model was not intended to be
substitutable by user-defined classes.

My proposal was cross-checked by someone else who came up with another
idea: make valarray and interface class template to STL containers
(a ``container adaptor'').

E.g. valarray<double, vector<double> > a(1000);

This leads to a very elegant connection with the rest of the libraries,
but IMO reintroduces constraints that lead to inefficiencies.

Given the reluctance to make any major change to the draft at this
stage, it is unclear (to me) whether any significant improvement will
be accepted (or even put up for a vote).

Note that neither proposal addresses aliasing better than the DWP; the
exploitation of non-aliasing will require special compiler support
(unless, say, the `restrict' keyword becomes standard).  OTOH, at
least one person has hinted that the current DWP text is not
sufficient to allow aggressive optimization (I understand this person
writes high-performance compilers).  
Two examples:
a) Generalized slices can be degenerate in the sense that:
	a[gslice(start, lengths, strides)]
   can contain an element of `a' more than once (apparently
   this hinders optimization),

b) void f(valarray<double>& a, valarray<double>& b);
   Unlike in Fortran, a and b are not guaranteed different.

	Daveed
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]