🚀 go-pugleaf

matt@godzilla.EECS.Berkeley.EDU (Matt Austern) wrote:
>In article <VANDEVOD.95Oct11203807@avs.cs.rpi.edu> vandevod@cs.rpi.edu (David Vandevoorde) writes:
>
>> Vaguely related:
>> 
>> Q. Is there a free implementation available of the valarray templates?
>> A. Not that I (we?) know of, but approximate implementations are
>>    available from:
>> 	ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray
>>    Non-commercial use is free.
>
>Which reminds me: I've heard rumors that there are known problems with
>the current definition of valarrays, that they don't actually solve
>the aliasing problems that they were supposed to.  I know no details.
>Has anyone else heard anything of this sort, and, if so, can you
>provide any specific information?
>
>If this is true, of course, then we can expect the final form of
>valarrays to differ from what we've seen in the draft standard.

There are a couple of proposals to change valarray floating
around at present: an extension to support a parameter 
controlling allocation category, and a proposal to replace
valarray with an STL container adaptor. Possibly these will
end up combined, and possibly it is too late in the standards
process for anything to change at all.

AFIK the existing valarray has appropriate constraints to
allow optimisations based on no aliasing, however there is
some concern that naive implementations will create
unnecessary copies of things.


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ 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. ]

>>>>> "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. ]