David Vandevoorde <daveed@vandevoorde.com> wrote:

>...
>Unfortunately, the valarray specs are quite bizarre
>in this (and other) respects. I tried having things
>fixed at some point, but failed. Applying the subset
>operators to a non-const valarray return something
>that can only be used for assignment or construction
>(essentially). OTOH, applying them to const valarrays
>typically generates large and/or complex temporaries.

>I'm afraid my recommendation would be not to use
>standard valarrays (they always end up being innefficient)
>and select an expression-template based library instead.
>Blitz++ seems quite promising...

> Daveed

I agree.
In a recent array class implementation, I initially planned to use the
valarray classes to implement the subarray and projection
functionality. I quickly found, however, that it was of no help as the
valarray slices have minimal functionality (e.g. one cannot do further
subsetting or projection on a gslice array) and once constructed one
cannot access the parameters used to construct them. For these
reasons, I was forced to duplicate the subsetting functionality in my
array class.

It seems to me that valarray was intended to simply be an interface to
fast parallel array hardware, in which case it may be useful, but it
is not very useful for implementing an array on a typical uniprocessor
machine (note 240 in the CD2 notwithstanding).

I am also not sure how the claimed temporary elimination of valarray
could be achieved- it will typically be buried within the
implementation of a user's class and so I don't see how even a
compiler that was aware of valarray could use the knowledge to
eliminate temporaries.

There is also the issue of its aliasing guarantees, but once one
starts using subarrays with reference semantics, I am not too sure
what advantage they would offer.

Can anyone shed some light on these issues?

Is anyone aware of any published design rationale for valarray, or of
its successfully use in any substantial array classes?

Valarray certainly looks intriguing, but I fear it may turn out to be
a bit of a white elephant.

,Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Brian Parker wrote:
[...]
> I am also not sure how the claimed temporary elimination of valarray
> could be achieved- it will typically be buried within the
> implementation of a user's class and so I don't see how even a
> compiler that was aware of valarray could use the knowledge to
> eliminate temporaries.

Well, all sorts of magic can presumably happen within a compiler.
However, a few paragraphs were added between CD1 and CD2 that
make implementation based on expression templates feasible in
principle (I say `in principle', because such an implementation
would be extremely messy.)

> There is also the issue of its aliasing guarantees, but once one
> starts using subarrays with reference semantics, I am not too sure
> what advantage they would offer.

At the Stockholm ISO/ANSI C++ meeting, Matt Austern remarked
that the aliasing properties specified for valarray were not
sufficient to be used effectively in implementations. At that
same meeting an attempt was made to address the issue, but
the resulting proposal did not inspire sufficient confidence
to make it into the standard.

> Can anyone shed some light on these issues?
>
> Is anyone aware of any published design rationale for valarray, or of
> its successfully use in any substantial array classes?

The original proposal that lead to valarray was considerably
simpler than what we have now. E.g., it was not a type template,
but rather a set of concrete arrays. I do believe that proposal
came with a rationale. Around that time, STL was introduced and
a movement to templatize just about any component in the standard
library also affected the valarray proposal (originally, it was
called numarray, I think). Although array implementations centered
around expression templates were floating around at the time,
these were unknown to whoever specified the valarray template
and so they did not take that possibility into account. I did
propose a total re-design of valarray, but the changes were too
drastic to be deemed acceptable at that late time (the proposal,
along with a buggy proof-of-concept implementation, should still
be available somewhere in
ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray/Documents).

> Valarray certainly looks intriguing, but I fear it may turn out to be
> a bit of a white elephant.

I'm not sure what a white elephant is, but I suspect I'll
agree with your fears.

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Brian Parker <bparker@gil.com.au> wrote:
: It seems to me that valarray was intended to simply be an interface to
: fast parallel array

or vector

: hardware,

I had the same feeling all time long. It's interesting to note that
Intel's MMX can not be abstracted this way, because C++ requires
arithmetic to wrap around, while MMX saturates.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David Vandevoorde <daveed@vandevoorde.com> wrote:
: The original proposal that lead to valarray was considerably
: simpler than what we have now. E.g., it was not a type template,
: but rather a set of concrete arrays. I do believe that proposal
: came with a rationale. Around that time, STL was introduced and
: a movement to templatize just about any component in the standard
: library also affected the valarray proposal (originally, it was
: called numarray, I think).

Yeh, but STLisation of valarray was half-harted. It doesn't have
an associated iterators and appropriate constructors.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi

Can anyone point me to some information on how to use the valarray and
slice classes of the standard library. My problem is this:

typedef valarray<double> dvarr;
dvarr x = some array of doubles...
int I = x.length()-1;
dvarr dx1 = (dvarr)x[slice(1, I, 1)] - (dvarr)x[slice(0, I, 1)];     <-
this vorks!
dvarr dx2 = x[slice(1, I, 1)] - x[slice(0, I, 1)]; <- this generates a
compiler error

What I need (I think) is to use the operator
valarray<T> operator[](slice sa) const;
but the compiler seems to select
slice_array<T> operator[](slice sa);
when it reaches the line
 dvarr dx2 = x[slice(1, I, 1)] - x[slice(0, I, 1)];
above. The error message I get is
 error C2678: binary '-' : no operator defined which takes a left-hand
operand of  type 'class slice_array<double>'
from the visual c++ 4.2 compiler.

Does anyone know how to use do this without casts (and preferably also
without the generation of temporary objects in complicated expressions)

Best regards,
Magnus Sundberg (sundberg@ifh.ee.ethz.ch)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Magnus Sundberg wrote:
[...]
> typedef valarray<double> dvarr;
> dvarr x = some array of doubles...
> int I = x.length()-1;
> dvarr dx1 = (dvarr)x[slice(1, I, 1)] - (dvarr)x[slice(0, I, 1)];
> <- this vorks!
> dvarr dx2 = x[slice(1, I, 1)] - x[slice(0, I, 1)];
> <- this generates a compiler error
>
> What I need (I think) is to use the operator
> valarray<T> operator[](slice sa) const;
> but the compiler seems to select
> slice_array<T> operator[](slice sa);
> when it reaches the line
>         dvarr dx2 = x[slice(1, I, 1)] - x[slice(0, I, 1)];
> above.

Unfortunately, the valarray specs are quite bizarre
in this (and other) respects. I tried having things
fixed at some point, but failed. Applying the subset
operators to a non-const valarray return something
that can only be used for assignment or construction
(essentially). OTOH, applying them to const valarrays
typically generates large and/or complex temporaries.

I'm afraid my recommendation would be not to use
standard valarrays (they always end up being innefficient)
and select an expression-template based library instead.
Blitz++ seems quite promising...

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]