Re: valarray

Re: valarray

[Jason Molenda]

Gabriel Dos Reis' mail system is having a little trouble contacting egcs,
he asked me to forward this note on for him.

----- Forwarded message -----

To: bkoz@nabi.net
Cc: Gabriel.Dos-Reis@cmla.ens-cachan.fr, egcs@egcs.cygnus.com,
        egcs-bugs@egcs.cygnus.com
Subject: Re: valarray
References: <371ACD62.68C7A607@nabi.net>
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
In-Reply-To: benjamin kosnik's message of "Mon, 19 Apr 1999 06:29:54 +0000"

benjamin kosnik <bkoz@nabi.net> writes:

| Hey Gaby, this is for when you get back so don't worry.
| 
| I've been working on trying to run the testsuite with -02, etc and making
| sure all the required instantiations are there, etc.
| 
| I get a bunch of warnings for valarray:
| 
| lArray,_Constant,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:487: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:487: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:487: warning:   instead of `typename
| _BinClos<_Oper,_ValArray,_Constant,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:487: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:494: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:494: warning:   instead of `typename
| _BinClos<_Oper,_Constant,_ValArray,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:494: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:497: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:497: warning:   instead of `typename
| _BinClos<_Oper,_Constant,_ValArray,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:497: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:497: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:497: warning:   instead of `typename
| _BinClos<_Oper,_Constant,_ValArray,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:497: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| 
| 
| etc etc etc--you might want to check into this when you get a chance.

Hi Benjamin!

The problem is in the C++ front end, and the error message is
bogus [cf. 14.6.1/3]: _Tp is a template parameter as you can see from
libstdc++/bits/valarray_meta.h:

// --line 480
    template<template<class> class _Oper, typename _Tp>
    struct _BinClos<_Oper,_ValArray,_Constant,_Tp,_Tp>
        : _BinBase2<_Oper,valarray<_Tp> > {
        typedef _BinBase2<_Oper,valarray<_Tp> > _Base;
        typedef typename _Base::value_type value_type;

        _BinClos (const valarray<_Tp>& __v, const _Tp& __t) // <===
                : _Base (__v, __t) {}
    };
// --line 490


That compiler bug should be fixed before egcs-1.2 gets out. IIRC it
wasn't present in egcs-2.93.15

| Also, I noticed that TNT, from the link on the main web page, uses both
| stringstreams and valarray, so I may try to get it up and running as part
| of the testing framework. I'll let you know how it goes.

Sounds great.

-- Gaby

----- End forwarded message -----

Re: valarray

[Jason Molenda]

Gabriel Dos Reis' mail system is having a little trouble contacting egcs,
he asked me to forward this note on for him.

----- Forwarded message -----

To: bkoz@nabi.net
Cc: Gabriel.Dos-Reis@cmla.ens-cachan.fr, egcs@egcs.cygnus.com,
        egcs-bugs@egcs.cygnus.com
Subject: Re: valarray
References: <371ACD62.68C7A607@nabi.net>
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
In-Reply-To: benjamin kosnik's message of "Mon, 19 Apr 1999 06:29:54 +0000"

benjamin kosnik <bkoz@nabi.net> writes:

| Hey Gaby, this is for when you get back so don't worry.
| 
| I've been working on trying to run the testsuite with -02, etc and making
| sure all the required instantiations are there, etc.
| 
| I get a bunch of warnings for valarray:
| 
| lArray,_Constant,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:487: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:487: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:487: warning:   instead of `typename
| _BinClos<_Oper,_ValArray,_Constant,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:487: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:494: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:494: warning:   instead of `typename
| _BinClos<_Oper,_Constant,_ValArray,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:494: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:497: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:497: warning:   instead of `typename
| _BinClos<_Oper,_Constant,_ValArray,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:497: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| ../bits/valarray_meta.h:497: warning: lookup of `_Tp' finds `class _Tp'
| ../bits/valarray_meta.h:497: warning:   instead of `typename
| _BinClos<_Oper,_Constant,_ValArray,_Tp,_Tp>::_Tp' from dependent base class
| ../bits/valarray_meta.h:497: warning:   (use `typename _BinClos::_Tp' if
| that's what you meant)
| 
| 
| etc etc etc--you might want to check into this when you get a chance.

Hi Benjamin!

The problem is in the C++ front end, and the error message is
bogus [cf. 14.6.1/3]: _Tp is a template parameter as you can see from
libstdc++/bits/valarray_meta.h:

// --line 480
    template<template<class> class _Oper, typename _Tp>
    struct _BinClos<_Oper,_ValArray,_Constant,_Tp,_Tp>
        : _BinBase2<_Oper,valarray<_Tp> > {
        typedef _BinBase2<_Oper,valarray<_Tp> > _Base;
        typedef typename _Base::value_type value_type;

        _BinClos (const valarray<_Tp>& __v, const _Tp& __t) // <===
                : _Base (__v, __t) {}
    };
// --line 490


That compiler bug should be fixed before egcs-1.2 gets out. IIRC it
wasn't present in egcs-2.93.15

| Also, I noticed that TNT, from the link on the main web page, uses both
| stringstreams and valarray, so I may try to get it up and running as part
| of the testing framework. I'll let you know how it goes.

Sounds great.

-- Gaby

----- End forwarded message -----

valarray

[Tobias Naehring]

When will ***valarray*** become part of egcs???

Best regards,
Tobias N"ahring

Re: valarray

[Gabriel Dos Reis]

>>>>> Tobias Naehring <naehring@eeetw6.et.tu-dresden.de> wrote:

Tobias> When will ***valarray*** become part of egcs???

Soon. Work is in progress. You may want to look at:
	
	http://egcs.cygnus.com/libstdc++-v3.html

Best,

-- Gaby

Re: valarray

[Ulrich Drepper]

mrs@wrs.com (Mike Stump) writes:

> It is a sad state of affairs when people donate code, and we still
> have nothing.  Is there a reason why we don't have the newer classes
> yet?  I think we have talked about it before, but I don't now recall
> what reason there may have been to not put it in.

It will be in the rewrite we'll have ready for the public sometime
very soon.  After this, I'll step back and let everybody else write
new code and patches and will concentrate incorporating the patch and
on keeping things in good shape and compilable.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: valarray

[Mike Stump]

> Date: Thu, 7 May 1998 03:12:00 +0200 (MET DST)
> Cc: egcs mailing list <egcs@cygnus.com>
> From: Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>

> Jochen> is there anything like the valarray templates with egcs.

> Actually I submitted a (almost) complete implementation, but you
> have to wait since it wasn't fully tested on all plaforms supported
> by egcs. It will be included in the newly rewritten libstdc++. I
> don't know when.

It is a sad state of affairs when people donate code, and we still
have nothing.  Is there a reason why we don't have the newer classes
yet?  I think we have talked about it before, but I don't now recall
what reason there may have been to not put it in.

If more work needs to be done on it to finish the work, drop it in,
and we can all work on it.

Re: valarray

[Jochen.K]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Thu, 07 May 1998, Gabriel Dos Reis wrote:
>>>>>> «Jochen», Jochen K"upper <jochen@uni-duesseldorf.de> wrote:

>There is an approximation written by Daveed Vandervood in the
>past. You should be able to get it somewhere on the net. Be aware that
>Daveed no longer maintains it.

Found it at ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray/Rel2_0Beta2/

Thanks,
Jochen

--
-----------------------------------------------------------------------
  Jochen K"upper

  Heinrich-Heine-Universit"at D"usseldorf   jochen@uni-duesseldorf.de
  Institut f"ur Physikalische Chemie I
  Universit"atsstr. 1, Geb 26.43 Raum 02.29    phone ++49-211-8113681
  40225 D"usseldorf                            fax   ++49-211-8115195
  Germany             http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------

valarray

[Jochen.K]

Dear All,

is there anything like the valarray templates with egcs. I did not find it when
looking through the header files.

As I understand from other sources (like Stroustrups The C++ Programming
Language) this is part of the standard library.

If there is no implementation with egcs, do you know any free implementations of
that conzept ?

Thanks you,
Jochen

--
-----------------------------------------------------------------------
  Jochen K"upper

  Heinrich-Heine-Universit"at D"usseldorf   jochen@uni-duesseldorf.de
  Institut f"ur Physikalische Chemie I
  Universit"atsstr. 1, Geb 26.43 Raum 02.29    phone ++49-211-8113681
  40225 D"usseldorf                            fax   ++49-211-8115195
  Germany             http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------

valarray

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

>>>>> «Jochen», Jochen K"upper <jochen@uni-duesseldorf.de> wrote:

Jochen> Dear All,
Jochen> is there anything like the valarray templates with egcs. I did not find it when
Jochen> looking through the header files.

Jochen> As I understand from other sources (like Stroustrups The C++ Programming
Jochen> Language) this is part of the standard library.

Actually I submitted a (almost) complete implementation, but you have
to wait since it wasn't fully tested on all plaforms supported by egcs. It
will be included in the newly rewritten libstdc++. I don't know when.


Jochen> If there is no implementation with egcs, do you know any free implementations of
Jochen> that conzept ?

There is an approximation written by Daveed Vandervood in the
past. You should be able to get it somewhere on the net. Be aware that
Daveed no longer maintains it.

-- Gaby

Re: valarray

[Nathan Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

Gabriel Dos Reis wrote:
> 
> >>>>> «Jochen», Jochen K"upper <jochen@uni-duesseldorf.de> wrote:
> Jochen> is there anything like the valarray templates with egcs. I did not 
> Jochen> find it when looking through the header files.
> 
> Jochen> As I understand from other sources (like Stroustrups The C++ Programming
> Jochen> Language) this is part of the standard library.
> 
> Actually I submitted a (almost) complete implementation, but you have
> to wait since it wasn't fully tested on all plaforms supported by egcs. It
> will be included in the newly rewritten libstdc++. I don't know when.

You should know that (as much as we appreciate Gabriel's contribution) 
that valarray is generally a poor way to accomplish what it was intended 
for.  A much better choice is something like Blitz++ or its kin, which you 
can find at (or by following links from)

  http://monet.uwaterloo.ca/blitz/

To perform well, valarray really needs special compiler support, and because
projects like Blitz++ have been so successful, valarray is unlikely ever to 
get that support.

Nathan Myers
ncm@cygnus.com

Re: valarray

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

>>>>> «Nathan», Nathan Myers <ncm@cygnus.com> wrote:

Nathan> You should know that (as much as we appreciate Gabriel's contribution) 
Nathan> that valarray is generally a poor way to accomplish what it was intended 
Nathan> for.  A much better choice is something like Blitz++ or its kin, which you 
Nathan> can find at (or by following links from)

Nathan>   http://monet.uwaterloo.ca/blitz/

Nathan> To perform well, valarray really needs special compiler support, and because
Nathan> projects like Blitz++ have been so successful, valarray is unlikely ever to 
Nathan> get that support.


Any efficient C/C++ library in numerical computation *needs* some
support from the compiler (e.g. keyword "restrict" in C). I know (in
some extent) very well the blitz project. Todd is aware (at least it
was pointed to him when he visited CERN recently) that the blitz
project, as it is now, is not usable in real world scientific
computing (e.g. in finite elements, large linear systems, systems from
physics). Nevertheless it introduced new concepts which deserve new
ways of optimization. 

Actually (as Bjarne told me in Sophia last March), the sade state of
valarray is a consequence of a lack of numerical computation expert in
the committee. It's just recently that I gained interest in using C++
in scientific computing. Anyway, I would really like to support an
efficient, usable valarray but for that I *need* some support form
folks here. I'm not a compiler designer but I can spend time to
learn gcc internals in order to get an efficient valarray if there
guys to explain me how things are made up.

-- Gaby

Re: valarray

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6687 bytes --]

>>>>> «David», David Banks <dbanks@cislunar.com> wrote:

David> Hi, 
David>    Do you have a reference or further explaination for this statement?
David> As near as I can tell, Blitz could be extremely useful as the compilers
David> are catching up to it. Maybe you see a problem in using it with unstructured/
David> adaptivly refined meshes while it could come in very handy for structured
David> and overset/chimera) paradigms?  Or is there something I'm missing and the
David> results quoted really aren't as good as they appear due to some paralyzing
David> constraint?


Blitz behaves very well for *medium arrays* and is very *clean* from a pure
C++ programmer view point. But (like valarray) blitz was not primarly
designed to serve the scientific computing community *but* to provide
an answer to a problem in C++. In that it succeeded (illustrating use
of expression template). The purpose of valarray was to provide
building blocks but it failed (for ex. almost every binary fonction
taking a valarray object an a builtin type does take a *const
reference* on the builtin type which is the most inefficient way to do
things. One might have expected to see a use of traits to decide
value/const ref according to sizeof of the type). Furthermore some
*fondamental* functions are missing (a mathematically sound inner
product on valarrays; why do we have valarray<>::sum() and not
valarray<>::product() ?) 

Blitz choises (for reasons I can undestand) not to give the same
meaning to the copy-ctor and the copy-assignment operator. This does
not only encourages aliasing (which prevents parallelism) but also
is error-prone. 

Below, I included an e-mail form Dag giving his impression on the
start of the art.


David> -Dave Banks
David> Cislunar Aerospace, inc
David> dbanks@cislunar.com

-- 
Gabriel Dos Reis                    | Ecole Normale Superieure de Cachan
INRIA, Unite de Recherche de        | Centre de Mathematiques et de Leurs
Sophia Antipolis                    |          Applications
Projet SAGA                         |       Equipe de Geometrie 


------- start of forwarded message (RFC 934 encapsulation) -------
Return-Path: <dag@dynasim.se>
Received: from net.dynasim.se (root@net.dynasim.se [192.16.137.60])
          by piano.dptmaths.ens-cachan.fr (8.8.8/jtpda-5.2) with ESMTP id PAA24587
          for <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>; Wed, 18 Mar 1998 15:51:49 +0100 (MET)
Received: from dag-nt (dag-nt.dynasim.se [194.103.53.10])
	by net.dynasim.se (8.8.8/8.8.8) with SMTP id PAA02644;
	Wed, 18 Mar 1998 15:54:55 +0100
Message-Id: <3.0.5.32.19980318155725.00960d30@194.103.53.1>
X-Sender: dag-pop@194.103.53.1
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
In-Reply-To: <199803171653.RAA12584@piano.dptmaths.ens-cachan.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Filter: mailagent [version 3.0 PL44] for dosreis@piano.ens-cachan.fr
From: Dag Bruck <dag@dynasim.se>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>
Cc: bs@research.att.com
Subject: Re: Numerics with C++
Date: Wed, 18 Mar 1998 15:57:25 +0100

Dear Gabriel,

At 17:53 1998-03-17 +0100, you wrote:
>
>Hello,
>=09
>	I am working on the class valarray from the C++ Standard
>Library. I discussed with Bjarne Stroustrup in Nice (France) last week
>about the implementation of valarray. He gave me your email suggesting=20
>to get in touch with you because you're specialist of numerics in both
>Fortran and C++. So I'm there.

I think that Bjarne Stroustrup was perhaps a little too enthusiastic about
my capabilities, but the company I work for is heavily involved in
efficient numerical simulation and we are right now looking at C/C++ matrix
libraries.

>	I would like to know if you're aware of an implementation of
>numerics library (other than Blitz++, TNT) in C++ that exhibits good
>performance. Would it be possible you give an explanation  of technics
>you use ?

What is the right library of course depends on your particular needs, and
ours are quite general, including LU and QR decomposition, handling of
sparse matrices etc. Another important aspect is a FORTRAN-compatible
storage format, because our customers want to interface to existing
libraries or code generated by f2c. We have looked at several libraries,
and currently we are probably most interested in a package called Meschach
( ftp://ftpmaths.anu.edu.au/pub/meschach/meschach.html ) because of its
overall functionality.

The Blitz++ package is probably the most exciting from a C++ perspective,
and should give very good performance for medium-sized matrices. Maybe
there are problems to get it to run on current compilers. The TNT library
is also quite good, and I know people who have used it with great success.
Here are some additional comments by a colleague of mine, Martin Otter:

- ----------------------------------------------------------------------------=
- -
I downloaded the TNT library when searching for sparse matrix=20
packages, but presently it seems to be that
no useful operations are provided (no sparse LU decomposition,=20
even no dense LU decomposition).
I looked at the packages on which TNT is based. These are packages
for dense matrices (LAPACK) and iterative sparse matrix packages
but no direct sparse matrix package for general matrices.=20
I therefore have the feeling,
that direct sparse matrix support will not be available or if
they plan to do it, it will come quite late, because they will first
implement the stuff they are familiar with.

The problem with iterative sparse matrix schemes is that no methods
seems to be known which work for all types of systems (which is of course
very important for a tool such as Dymola). Direct sparse matrix schemes
seem to be much more robust with respect to the system to be solveed.
On the other hand, very big systems (dim > 100 000) seem to be only
solvable by iterative methods.
- ----------------------------------------------------------------------------=
- -

In our application, symbolic transformations that take advantage of zero
elements results in runtime performance that a pure numerical approach
cannot match. Our product is an object-oriented modeling and simulation
environment for large continuous systems (with discrete events).

If we are primarily interested in implementing valarray, TNT is probably a
good choice.

Best regards,

Dag Br=FCck
- --
Dynasim AB                      Phone:  +46 46 182500
Research Park Ideon             FAX:    +46 46 182501
S-223 70 Lund                   E-mail: dag@Dynasim.se
Sweden                          URL:    http://www.Dynasim.se
------- end -------