Ralf Stoffels <stoffels@faho.rwth-aachen.de> wrote:

>The draft standard says:
>"the valarray template is neither a   matrix class nor a field class.
>  However, it is a very useful building block for designing such
>classes."

>Does anyone knows a matrix class, which is based on <valarray> ?


>Ralf
>---

That is the $64,000 question.

Valarray has certainly been around long enough to prove its worth, at
least experimentally.
I haven't found it to be a useful building block for matrix classes,
but hopefully there are examples of its successful use.
If not, then I think the committee should seriously consider removing
it from the standard, until more experience with it is obtained. If it
is a part of the final standard and is found to be less than useful in
practice then it will be difficult to remove it at a later standard
revision, IMO.

,Brian Parker (bparker@gil.com.au)




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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                             ]

Ralf Stoffels (stoffels@faho.rwth-aachen.de) wrote:
> The draft standard says:
> "the valarray template is neither a   matrix class nor a field class.
>   However, it is a very useful building block for designing such
> classes."

> Does anyone knows a matrix class, which is based on <valarray> ?

 I believe that GNUSSL, "the GNU Scientific Software Library",
does this or something very similar. It's available from any of the
GNU site mirrors, ftp://wuarchive.wustl.edu/systems/gnu/ for example.

-------------------------------------------------------------------------
-
Dave Steffen                      Wave after wave will flow with the
tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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 <bparker@gil.com.au> wrote:
: Valarray has certainly been around long enough to prove its worth, at
: least experimentally.
: I haven't found it to be a useful building block for matrix classes,
: but hopefully there are examples of its successful use.
: If not, then I think the committee should seriously consider removing
: it from the standard, until more experience with it is obtained. If it
: is a part of the final standard and is found to be less than useful in
: practice then it will be difficult to remove it at a later standard
: revision, IMO.

I think I've posted this though already, but let me rehash it again.
Valarray was not supposed IMHO to be a building block for vector/matrix
classes. It was probably just an attempt to provide an abstraction
for vector/parallel computer architectures.

C gained such an incredible popularity IMHO solely because it provided
good implementation of the just right "hardware platform" abstraction.
I think it's extremely important that C++ continues developing this
trend. Whether valarray is a correct implementation of the correct
abstraction, I don't really know. Seems to be so, but unless I or the
C++ community have more experience with it, it's hard for me to tell.

Maybe it's a correct abstraction of a single parallel/vector CPU, but
the wrong abstraction of the multiple symmetric or massively parallel
"hardware platform". Who knows. If it is not, I think that DRASTIC
measures have to be taken IMMEDIATELY.

And finally: everything above are my guesses, based on nothing.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Oleg Zabluda wrote:
[...]
> I think I've posted this though already, but let me rehash it again.
> Valarray was not supposed IMHO to be a building block for
> vector/matrix classes. It was probably just an attempt to provide an
> abstraction for vector/parallel computer architectures.

As I recall, the original valarray proposal paper _did_ target
valarray (numarray) as a building block for matrix and vector
classes (but not _only_ for this purposes). Although I don't think
that abtraction of parallel architectures was the primary motivation,
the interface certainly looks like data-parallelism was intended
to be exploited where possible.

> C gained such an incredible popularity IMHO solely because it provided
> good implementation of the just right "hardware platform" abstraction.
> I think it's extremely important that C++ continues developing this
> trend. Whether valarray is a correct implementation of the correct
> abstraction, I don't really know. Seems to be so, but unless I or the
> C++ community have more experience with it, it's hard for me to tell.

My opinion differs here (i.e., I think the valarray abtraction is
not a good one).

> Maybe it's a correct abstraction of a single parallel/vector CPU, but
> the wrong abstraction of the multiple symmetric or massively parallel
> "hardware platform". Who knows. If it is not, I think that DRASTIC
> measures have to be taken IMMEDIATELY.

I wouldn't mind a standard without valarrays, but I don't think
they are truly a problem from an uninterested user's perspective.
It's too late to replace them, but they don't impact other library
aspects. We can just ignore that part of the library.

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

Oleg Zabluda <zabluda@math.psu.edu> wrote:

>Brian Parker <bparker@gil.com.au> wrote:
>: Valarray has certainly been around long enough to prove its worth, at
>: least experimentally.
>: I haven't found it to be a useful building block for matrix classes,
>: but hopefully there are examples of its successful use.
>: If not, then I think the committee should seriously consider removing
>: it from the standard, until more experience with it is obtained. If it
>: is a part of the final standard and is found to be less than useful in
>: practice then it will be difficult to remove it at a later standard
>: revision, IMO.

>I think I've posted this though already, but let me rehash it again.
>Valarray was not supposed IMHO to be a building block for vector/matrix
>classes. It was probably just an attempt to provide an abstraction
>for vector/parallel computer architectures.

>C gained such an incredible popularity IMHO solely because it provided
>good implementation of the just right "hardware platform" abstraction.
>I think it's extremely important that C++ continues developing this
>trend. Whether valarray is a correct implementation of the correct
>abstraction, I don't really know. Seems to be so, but unless I or the
>C++ community have more experience with it, it's hard for me to tell.

>Maybe it's a correct abstraction of a single parallel/vector CPU, but
>the wrong abstraction of the multiple symmetric or massively parallel
>"hardware platform". Who knows. If it is not, I think that DRASTIC
>measures have to be taken IMMEDIATELY.

>And finally: everything above are my guesses, based on nothing.

>Oleg.

Yes, valarray may be a useful interface to fast hardware and perhaps
those more knowledgable in this area have already shown it to be so,
however my concerns are as follows.

For element-wise array operations, one needs to bring together all the
operands of an expression (i.e.  loop fusion) to avoid temporaries and
for maximum speed, whether on a uniprocessor or parallel hardware. Now
there are two ways that this could be achieved with valarray-
(1) At the source level using expression templates-based techniques.
(2) Within the compiler's optimiser.

In the first case, in my experience, valarray is not very useful
because valarray is not directly usable in expressions. Therefore the
deferred evaluation using expression templates needs to be done on the
user's array class. Having deferred the evaluation of the expression,
the implementation could then use valarray internally, but by this
stage it would me more useful to simply have a functional interface to
fast parallel routines (sort of an element-wise "BLAS") rather than go
back to the potentially pair-wise evaluation of valarray, which will
always have more overhead than a simple functional interface. For
example, in a matrix/array class I wrote using an expression
templates-based technique (http://www.gil.com.au/~bparker) I
eventually used a functional interface as the available valarray
implementation would have had too much overhead and would not be
suitable for the kinds of image processing operations I will need to
add. (perhaps standardising a functional interface to parallel
hardware would be useful- but not for the C++ standard IMO).

In the second case, because valarray is standardised, the compiler
could potentially be smart enough to look for valarray within an
implementation and then use it to avoid temporary production. It just
seems to me though that this will be difficult for a compiler. If
valarray was a directly usable array class (say a Fortran 90-like
array) then it would be directly visible in expressions and easily
optimised. But valarray will be buried deep within a user's array
class and that would seem to make optimisation more difficult. Also,
because the slice et. al. subsetting classes of valarray are also not
directly useful, the user will have their own array section classes
and again it would seem to be difficult for a compiler to rule out
aliasing under these conditions.

In summary, IMO valarray is at an uncomfortable level of abstraction-
lower than a directly usable array class, but higher than a simple
functional interface. I think valarray would only be useful with
extensive compiler support, and because of the effort involved in
this, it is all the more important that it be suitable for this
purpose and its utility demonstrated by measurements on experimental
compiler implementations. This may already have been done, but I don't
know of any published results, and if any doubts remain then it may be
better to experiment with it as a de facto standard until more
experience has been obtained.

Of course, my fears are probably unfounded and those in the know may
already be achieving useful results with valarray- I would be
interested in references to any published data on this subject.

,Brian Parker (bparker@gil.com.au)




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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                             ]

The draft standard says:
"the valarray template is neither a   matrix class nor a field class.
  However, it is a very useful building block for designing such
classes."

Does anyone knows a matrix class, which is based on <valarray> ?


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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]