Jurgen Singer wrote:

> 1. I don't think the above solution is correct, since for a
> valarray  &x[0] is a pointer - and a pointer and an iterator are
> two different things (though commonly iterators are implemented
> as pointers, but there is no requirement that they are). So I am
> not saying that the above solution would not work in most
> implementations, but that the standard does not guarantee that
> it will work.

An iterator is anything that meets the iterator requirements. Those
requirements were specifically constructed to mirror the characteristics
of pointers. A pointer automatically satisfies every single iterator
requirement.
In addition, just to make things easier, iterator_traits is partially
specialized for T*, to give exactly the right results.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jurgen Singer <jurgen@aNOcSPAMm.org> wrote:
>...  compilers which can actually compile Blitz are just starting
>to get wide-spread (e.g., you need egcs 1.1, 1.0 won't do).
>So if I have a choice between a widely supported, standardized
>language and a non-standard library which may or may not compile
>on the platform to which I want to port my code, the choice is
>obvious. I won't even mention issues related to moving to parallel
>machines.

Any standard-conforming compiler can compile Blitz++, and many
that are not can do so, also.   Of course there are other math
libraries as well.

Fortran compilers that support the optimizations that are possible
to do in a library are (and will remain) much rarer than C++
compilers that can compile these libraries.  C++ library
technology is in its infancy, and can respond much faster to
new developments than compiler writers.  (So, what's wrong
with using Egcs-1.1 on your target?)

>Wy current view is, that C++ does currently not offer a reliable
>path to high performance numerics. I am sure that this will change
>within the next 5 years. I would hope that valarray will be removed
>from the standard (for starters, marked as obsolete). I agree that
>Blitz offers some promise, but for it to be considered for
>important applications it will have to get more widespread support
>(prefereably be incorporated into the standard)

I hope we have learned our lesson about standardizing array math
libraries.  The language supports good ones, and there seems to
be little need to choose one as universally "better" than the
others.

>With regard to C++: Its major problem is that it is trying to be
>a Jack of all trades - this leads to a way too complicated standard.

It is an unspecialized language, well suited to uses that have
not been named.  Numerics is a mature field that should be able
to support specialized languages.  Most fields are not so mature,
and most never will be, but C++ is there for them.

>One way out of this may be to split the standard into several
>parts with appropriate sub-systems (Core Language, Numerics, etc.)

Or just the Core Language.  C++ numerics seems to be doing fine
with little help from ISO, and might have done even better with less
help.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36372CD8.F9F23438@aNOcSPAMm.org>, Jurgen Singer
<jurgen@aNOcSPAMm.org> writes
>And that C++ has made some inroads towards Scientific Computing,
>as you can infear from the fact that when I posted a similar
>remark about norm(complex<T>) and inner_product about one year
>ago to this group (albeit in less provocative language), there
>was just 1 response - since apparently nobody was interested in
>doing numerics with C++.

You mean, of course, nobody reading comp.std.c++.  And that is the real
crux of the problem.  If those with expertise in an area do not share it
with those working on standards nothing can be done (or that which is
done may be incorrect.)


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> James Kuyper wrote:
> >But the language he was talking about was Fortran 90. How would you
> >describe Fortran 90 in these terms? I'd personally say it has a very
> >definite concept of value.
>
> No, not quite.  He went on to say that when he wanted to use OOP he
> would use Smalltalk or Scheme.  It was at that that my comment was
> aimed.

You are both right: I said that I would wrap my Fortran applications
into Smalltalk (Scheme). In terms of performance those languages
cannot compete with Fortran, but Fortran does currently not offer
the full range of object-oriented capabilities. But it is not
too difficult to remedy that with mixed language programming.

-- Jurgen
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <715b7j$gq6$1@shell7.ba.best.com>,
Nathan Myers <ncm@nospam.cantrip.org> wrote:
>> I had programmed scientific applications in C++ since
>> 1988, but now I have moved over to Fortran 90, which
>> is a much more sane language for numerics - I suspect
>> the main reason is that Fortran is highly disregarded by
>> computer scientists, which luckily leads them to mostly
>> ignore it. If I need something more object-oriented I'll
>> wrap my Fortran code into Smalltalk or Scheme -
>> as far as I can see, C++ is a dead end, at least for
>> numerical applications. There are just too many hoops
>> to jump through and pitfalls to avoid, just to get the
>> same performance as a straight Fortran program.
>
>Evidently you don't know about the progress that has been made
>in C++ numerics independent of the standard effort.  Start with
>http://monet.uwaterloo.ca/blitz/.  C++ is beating Fortran 90 by
>every measure.

I do now about Blitz++, and unfortunately Blitz++ is currently of
marginal interest as a linear algebra package, but interesting
as a an multi-dimensiaonl array-template.

I believe one problem is that Blitz++ sees templates as the
only solution. This is fine for arrays and C++ compilers now seem
to get similar performance from Fortran and Blitz++ code,
but the Blitz++ still lacks LU,QR,eigenvalue-decompositions (and
other useful routines).

The simplest way to include the functionality into Blitz++ is of course
to link to pre-existing Lapack libraries (re-use!), but at least
I didn't find on the Blitz++ homepage.
I've used this alternative myself, as compiler support for
the complex templates used by Blitz++ have only recently arrived.









--
// Home page  http://www.dna.lth.se/home/Hans_Olsson/
// Email To..Hans.Olsson@dna.lth.se [Please no junk e-mail]
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hans Olsson<Email_To::.Hans.Olsson@dna.lth.se> wrote:
>Nathan Myers <ncm@nospam.cantrip.org> wrote:
>>
>>Evidently you don't know about the progress that has been made
>>in C++ numerics independent of the standard effort.  Start with
>>http://monet.uwaterloo.ca/blitz/.  C++ is beating Fortran 90 by
>>every measure.
>
>I do now about Blitz++, and unfortunately Blitz++ is currently of
>marginal interest as a linear algebra package, but interesting
>as a an multi-dimensional array-template.

Blitz++ is interesting in itself, but is also interesting as
exemplar of a family of libraries addressing numerics.  On the
blitz page you can find links to POOMA, MTL, and other
libraries addressing other aspects of high-performance
numerics.

It is this diversity that suggests a "standard" array library
was and would be a mistake.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <xajpvbdsk3s.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
<gdosreis@sophia.inria.fr> wrote:
> I think the main problem Jurgen Singer was trying to point out isn't
> the syntaxe but the semantic of inner_product<>(). As defined in
> 26.4.2/1 it fails to meet the common mathematical meaning (therefore
> useless in numeric computation) of inner product when provided with
> iterators whose value_types are complex<T>. It should have been
> defined as:
>
>         acc = acc + (*i1) * conj(*i2)

I agree that inner_product was a bad name, especially for the "numeric"
library, but at least the more generic version of inner_product meets the
generic meaning of "inner product," that is "accummulate the element-wise
combinations of two sets."  Here "accummulate" is defined by the first
binary operator template parameter, and "combination" is defined by the
second.  So you can make a binary operator that does LHS * conj(RHS), and
you're all set.

Elron A. Yellin


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <36364823.167E@wizard.net>, James Kuyper <kuyper@wizard.net>
> writes
> >> You mean you prefer to do your numerics in a language that lacks a
> >> concept of value? ...
> >
> >OK - you've piqued my curiosity. What does that statement mean?
>
> In Smalltalk everything is an object
>
> In C everything is a value
>
> In Java built-ins are values and user-defineds are objects
>
> In C++ built-ins are values but you make your own choice for all other
> types.
>
> Each approach has its gains and losses, but you ought to know what they
> are.  Smalltalk is great for many things but you need to contort your
> thinking when doing numerics in it.

But the language he was talking about was Fortran 90. How would you
describe Fortran 90 in these terms? I'd personally say it has a very
definite concept of value.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
> On 27 Oct 98 20:43:24 GMT, Svante Eriksson <d2ser@dtek.chalmers.se> wrote:
> >Jurgen Singer wrote:
>
> >> [...] and the C++ numerics templates, like
> >> inner_product, require iterator arguments, which means
> >> they won't work with valarrays.
> >
> >They do.  res=inner_product(&x[0],&x[x.size()],&y[0],0.0);
>
> This is undefined behaviour.  x[x.size()] accesses the array out of
> bounds.  After all, an implementation is free to do run time array

x[x.size()] is never accessed, since &x[x.size()] is merely used as a
past-the-end iterator, like &y[10] in the following snippet:
  double y[10];
  ...
  res=inner_product(&y[0],&y[10],0.);

I believe there are some examples in Stroustrup's 3rd regarding the
use of standard algorithms with valarray.

/ser

--
svante eriksson, cs/ce, chalmers university of technology
d2ser@dtek.chalmers.se, http://www.dtek.chalmers.se/~d2ser
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3636ABE5.D1DF98F1@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>But the language he was talking about was Fortran 90. How would you
>describe Fortran 90 in these terms? I'd personally say it has a very
>definite concept of value.

No, not quite.  He went on to say that when he wanted to use OOP he
would use Smalltalk or Scheme.  It was at that that my comment was
aimed.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paris (U.E.), le 28/10/1998

 Still, valarray can be useful for number crunching, for some platforms.
More precisely, for Morolola's (and IBM's?) Altivec architecture, some
vector-like operations are quite accelerated. We are trying to convince
Metrowerks (which is about the sole C++ compiler writer for MacOS, which
hopefully will use that technology), to use these kind of instructions
when possible when faced with a valarray. This of course does not
preclude the use of techniques such as those of Blitz++.

  Hubert Holin
  Hubert.Holin@Bigfoot.com
  http://www.bigfoot.com/~Hubert.Holin


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>>  Biju Thomas <bijuthom@ibm.net> wrote:

> Gabriel Dos_Reis wrote:
>>
>> I think the main problem Jurgen Singer was trying to point out isn't
>> the syntaxe but the semantic of inner_product<>(). As defined in
>> 26.4.2/1 it fails to meet the common mathematical meaning (therefore
>> useless in numeric computation) of inner product when provided with
>> iterators whose value_types are complex<T>. It should have been
>> defined as:
>>
>> acc = acc + (*i1) * conj(*i2)

> This can become difficult, as conj() is not defined for all types. If

The point is not to make work with any type. The intent is to make it
work with the more fondamental numerical types (float, double, long
double). Yes, that would require a conj() for float, double, and long
double.

> you want to have this meaning for the norm of complex numbers, why not
> use the second version of inner_product which takes binary operators as
> parameters.

Yes I do know.

> template <class InputIterator1,
>           class InputIterator2,
>           class T,
>           class BinaryOperation1,
>           class BinaryOperation2>
> T inner_product(InputIterator1 first1,
>                 InputIterator1 last1,
>                 InputIterator2 first2,
>                 T init,
>                 BinaryOperation1 binary_op1,
>                 BinaryOperation2 binary_op2);

> It's meaning is defined as
>           acc = binary_op1(acc,binary_op2(*i1,*i2))

Is it more intuitive and less painful even though it is technically correct?

--
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos_Reis wrote:
>
> sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:
>
> > On 27 Oct 98 20:43:24 GMT, Svante Eriksson <d2ser@dtek.chalmers.se> wrote:
> > >They do.  res=inner_product(&x[0],&x[x.size()],&y[0],0.0);

> I think the main problem Jurgen Singer was trying to point out isn't
....<snip>
 iterators whose value_types are complex<T>. It should have been
> defined as:
>
>         acc = acc + (*i1) * conj(*i2)
> or ...
>
I choose this example for both reasons:
1. I don't think the above solution is correct, since for a
valarray  &x[0] is a pointer - and a pointer and an iterator are
two different things (though commonly iterators are implemented
as pointers, but there is no requirement that they are). So I am
not saying that the above solution would not work in most
implementations, but that the standard does not guarantee that
it will work.

2. Indeed, the default behavior of inner_product should give the
mathematically correct inner product - with the inner_product
definition in C++ you have to give additional arguments to
achieve this.

-- Jurgen
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Svante Eriksson wrote:

> x[x.size()] is never accessed,

It is dereferenced, as a[b] is just *(a+b), leading to
undefined behaviour.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>> =ABElron=BB, Elron A Yellin <elron@alum.mit.edu> wrote:

[...]

> I agree that inner_product was a bad name, especially for the "numeric"
> library, but at least the more generic version of inner_product meets t=
he
> generic meaning of "inner product," that is "accummulate the element-wi=
se
> combinations of two sets."  Here "accummulate" is defined by the first
> binary operator template parameter, and "combination" is defined by the
> second.  So you can make a binary operator that does LHS * conj(RHS), a=
nd
> you're all set.

I agree, but I think the more general version should be for "general
inner product" (f.e. non degenerate bilinear symmetric forms) and
the "specilized" one for the common case, that is it should work for
floatings as well as complexes. IMHO it should have been more intuitive
and less too specialized.

--=20
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>
> Evidently you don't know about the progress that has been made
> in C++ numerics independent of the standard effort.  Start with
> http://monet.uwaterloo.ca/blitz/.  C++ is beating Fortran 90 by
> every measure.
>
I have been aware of Blitz for some time now - and Blitz is not
"beating" Fortran, it is about even. However, compilers which can actually compile Blitz are just starting to get wide-spread (e.g.,
you need egcs 1.1, 1.0 won't do).
So if I have a choice between a widely supported, standardized
language and a non-standard library which may or may not compile
on the platform to which I want to port my code, the choice is obvious. I won't even mention issues related to moving to parallel
machines.

It was even more obvious when I started on my current project
about one year ago. And I don't think that I will throw away
what I have written during the last year, just to move back
to C++ again.

Wy current view is, that C++ does currently not offer a reliable
path to high performance numerics. I am sure that this will change
within the next 5 years. I would hope that valarray will be removed
from the standard (for starters, marked as obsolete). I agree that
Blitz offers some promise, but for it to be considered for
important applications it will have to get more widespread support
(prefereably be incorporated into the standard)

With regard to C++: Its major problem is that it is trying to be
a Jack of all trades - this leads to a way too complicated standard.

One way out of this may be to split the standard into several
parts with appropriate sub-systems (Core Language, Numerics, etc.)

And that C++ has made some inroads towards Scientific Computing,
as you can infear from the fact that when I posted a similar
remark about norm(complex<T>) and inner_product about one year
ago to this group (albeit in less provocative language), there
was just 1 response - since apparently nobody was interested in
doing numerics with C++.

-- Jurgen
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> >"Norm" is defined very formally in vector mathematics.
> >Although the definition allows room for several distinct norms, even in
> >2-dimensional vector spaces, the squared euclidian distance to zero is NOT a
> >norm, since it fails to meet the triangle inequality. The euclidian distance
> >to zero DOES meet this requirement. So, as far as I can see, there is little
> >or no room for discussion.
>
> By that standard, there is no room for discussion at all.
> The standard has been published, and the C++ norm is (AFAIK)
> the same as the Fortran norm -- end of story.
>
> If you were to define your own complex<> library (which I encourage)
> you would probably better call the equivalent function "norm2".
>
There is no standard norm routine in Fortran. As for
defining your own complex<> library: Why bother, there
is perfectly good complex support in Fortran.
I complained about the wrong implementation of complex
norm and inner_product to the Standard comittee after I
found out last October, and was told that the time for
public comment is over.

Equally, the ill conceived valarray is supposed to be
used for numeric applications, but some of the most
common operations done in scientifc codes are
dot products - and the C++ numerics templates, like
inner_product, require iterator arguments, which means
they won't work with valarrays.

One of the problems seems to be that the C++ Standard
was written by computer scientist, who apparently don't
know too much about mathematics. Another problem is
that C++ has taken the Microsoft route: get something
out, even if it is low quality, not well thought out
and bloated, but I am rambling.

I had programmed scientific applications in C++ since
1988, but now I have moved over to Fortran 90, which
is a much more sane language for numerics - I suspect
the main reason is that Fortran is highly disregarded by computer scientists, which luckily leads them to mostly
ignore it. If I need something more object-oriented I'll
wrap my Fortran code into Smalltalk or Scheme -
as far as I can see, C++ is a dead end, at least for
numerical applications. There are just too many hoops
to jump through and pitfalls to avoid, just to get the
same performance as a straight Fortran program.

-- Jurgen
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jurgen Singer <jurgen@aNOcSPAMm.org> writes:

> There is no standard norm routine in Fortran. As for
> defining your own complex<> library: Why bother, there
> is perfectly good complex support in Fortran.
> I complained about the wrong implementation of complex
> norm and inner_product to the Standard comittee after I
> found out last October, and was told that the time for
> public comment is over.

But now that C++ is standardized the committe will issue defect
reports.

>
> Equally, the ill conceived valarray is supposed to be
> used for numeric applications, but some of the most
> common operations done in scientifc codes are
> dot products - and the C++ numerics templates, like
> inner_product, require iterator arguments, which means
> they won't work with valarrays.
>

Well, valarray has had a curious history. I'm planning to add most
useful functions (missing in the standard) to the EGCS/libstc++-v3
implementation. One can hope that users concerned with valarray will
lobby their vendors to do similar extensions.

> One of the problems seems to be that the C++ Standard
> was written by computer scientist, who apparently don't
> know too much about mathematics. Another problem is

This is a rather severe assertion.

> that C++ has taken the Microsoft route: get something
> out, even if it is low quality, not well thought out
> and bloated, but I am rambling.
>

At the time valarray was designed, there was no support for number
crunching. I don't think in this particular case that nothing is
better than anything. It's admitted that valarray<> was not well
designed; this is mainly beacause the scientific computing community
was absent in the standardization process. At the time they realized
they could benefit from the C++ expressiveness it was too late.

Best,

--
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3635BD0F.2507CD72@aNOcSPAMm.org>, Jurgen Singer
<jurgen@aNOcSPAMm.org> writes
>I complained about the wrong implementation of complex
>norm and inner_product to the Standard comittee after I
>found out last October, and was told that the time for
>public comment is over.

However you can always raise it as a maintenance issue.
>
>Equally, the ill conceived valarray is supposed to be
>used for numeric applications, but some of the most
>common operations done in scientifc codes are
>dot products - and the C++ numerics templates, like
>inner_product, require iterator arguments, which means
>they won't work with valarrays.

Any group can only work with the resources they have.  Unfortunately
even those that had the requisite numerical expertise found their
employers demanding they pay more attention to the core business

>
>One of the problems seems to be that the C++ Standard
>was written by computer scientist, who apparently don't
>know too much about mathematics. Another problem is
>that C++ has taken the Microsoft route: get something
>out, even if it is low quality, not well thought out
>and bloated, but I am rambling.

I think that is a very jaundiced attitude.  Of course there are a large
number of flaws in the C++ Standard but unlike Microsoft we will not be
issuing a new version with another set of flaws next year.  With help
C++ can become better (fewer defects) over the next five years.

As to bloated, you should see what we left out :)

>
>I had programmed scientific applications in C++ since
>1988, but now I have moved over to Fortran 90, which
>is a much more sane language for numerics - I suspect
>the main reason is that Fortran is highly disregarded by computer scientists,
>which luckily leads them to mostly
>ignore it.
I am having difficulty with this characterisation of Computer
Scientists.  I have met more of those in the Fortran World than I ever
have in the C++ Standards World.  Indeed the general complaint about C++
has been too little computer science and too much pragmatism in contrast
to Smalltalk and Eiffel.

>If I need something more object-oriented I'll
>wrap my Fortran code into Smalltalk or Scheme -
>as far as I can see, C++ is a dead end, at least for
>numerical applications. There are just too many hoops
>to jump through and pitfalls to avoid, just to get the
>same performance as a straight Fortran program.

You mean you prefer to do your numerics in a language that lacks a
concept of value?  BTW at least one C++ compiler supports extern
"Fortran" which allows access to (among others) the NAG Fortran
Libraries.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jurgen Singer wrote:

> [...] and the C++ numerics templates, like
> inner_product, require iterator arguments, which means
> they won't work with valarrays.

They do.  res=inner_product(&x[0],&x[x.size()],&y[0],0.0);

/ser

--
svante eriksson, cs/ce, chalmers university of technology
d2ser@dtek.chalmers.se, http://www.dtek.chalmers.se/~d2ser
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jurgen Singer <jurgen@aNOcSPAMm.org> wrote:
> ... the ill conceived valarray is supposed to be
> used for numeric applications, but some of the most
> common operations done in scientifc codes are
> dot products - and the C++ numerics templates, like
> inner_product, require iterator arguments, which means
> they won't work with valarrays.

Valarray is not "supposed to be" used for numeric applications;
it *can be* used.  There are better alternatives available, free,
now.  At the time valarray was put in, these techniques were not
known, but it could not be removed without delaying the standard.
Feel free to ignore it.

> One of the problems seems to be that the C++ Standard
> was written by computer scientist, who apparently don't
> know too much about mathematics. Another problem is
> that C++ has taken the Microsoft route: get something
> out, even if it is low quality, not well thought out
> and bloated, but I am rambling.

Yes, you are rambling.  The problem was that the C++ Standard
was written by overworked volunteers.  Had you offered to put
in time to help out as we did -- in any area -- the result
would very likely have been different, maybe better.

> I had programmed scientific applications in C++ since
> 1988, but now I have moved over to Fortran 90, which
> is a much more sane language for numerics - I suspect
> the main reason is that Fortran is highly disregarded by
> computer scientists, which luckily leads them to mostly
> ignore it. If I need something more object-oriented I'll
> wrap my Fortran code into Smalltalk or Scheme -
> as far as I can see, C++ is a dead end, at least for
> numerical applications. There are just too many hoops
> to jump through and pitfalls to avoid, just to get the
> same performance as a straight Fortran program.

Evidently you don't know about the progress that has been made
in C++ numerics independent of the standard effort.  Start with
http://monet.uwaterloo.ca/blitz/.  C++ is beating Fortran 90 by
every measure.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 27 Oct 98 20:43:24 GMT, Svante Eriksson <d2ser@dtek.chalmers.se> wrote:
>Jurgen Singer wrote:

>> [...] and the C++ numerics templates, like
>> inner_product, require iterator arguments, which means
>> they won't work with valarrays.
>
>They do.  res=inner_product(&x[0],&x[x.size()],&y[0],0.0);

This is undefined behaviour.  x[x.size()] accesses the array out of
bounds.  After all, an implementation is free to do run time array
bounds checking.  This is good for debugging.  Of course, a compiler
option should turn this checking off (for the optimized, production
version).  So use this

res=inner_product(&x[0],&x[0]+x.size(),&y[0],0.0);

But the spirit of what you say is entirely correct.  They really
should have put begin() and end() functions in valarray.  Maybe we
can submit this in a bug report.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <3635BD0F.2507CD72@aNOcSPAMm.org>, Jurgen Singer
> <jurgen@aNOcSPAMm.org> writes
...
> >1988, but now I have moved over to Fortran 90, which
> >is a much more sane language for numerics - I suspect
...
> You mean you prefer to do your numerics in a language that lacks a
> concept of value? ...

OK - you've piqued my curiosity. What does that statement mean?


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:

> On 27 Oct 98 20:43:24 GMT, Svante Eriksson <d2ser@dtek.chalmers.se> wro=
te:
> >Jurgen Singer wrote:
>=20
> >> [...] and the C++ numerics templates, like
> >> inner_product, require iterator arguments, which means=20
> >> they won't work with valarrays.
> >
> >They do.  res=3Dinner_product(&x[0],&x[x.size()],&y[0],0.0);
>=20
> This is undefined behaviour.  x[x.size()] accesses the array out of
> bounds.  After all, an implementation is free to do run time array
> bounds checking.  This is good for debugging.  Of course, a compiler
> option should turn this checking off (for the optimized, production
> version).  So use this
>=20
> res=3Dinner_product(&x[0],&x[0]+x.size(),&y[0],0.0);
>=20
> But the spirit of what you say is entirely correct.  They really
> should have put begin() and end() functions in valarray.  Maybe we
> can submit this in a bug report.

I think the main problem Jurgen Singer was trying to point out isn't
the syntaxe but the semantic of inner_product<>(). As defined in
26.4.2/1 it fails to meet the common mathematical meaning (therefore
useless in numeric computation) of inner product when provided with
iterators whose value_types are complex<T>. It should have been
defined as:=20

 acc =3D acc + (*i1) * conj(*i2)
or ...

--=20
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jurgen Singer wrote:
....
> > The standard has been published, and the C++ norm is (AFAIK)
> > the same as the Fortran norm -- end of story.
> >
> > If you were to define your own complex<> library (which I encourage)
> > you would probably better call the equivalent function "norm2".
> >
> There is no standard norm routine in Fortran. As for
> defining your own complex<> library: Why bother, there
> is perfectly good complex support in Fortran.

Because I want to use other features of C++, with complex numbers.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos_Reis wrote:
>
> I think the main problem Jurgen Singer was trying to point out isn't
> the syntaxe but the semantic of inner_product<>(). As defined in
> 26.4.2/1 it fails to meet the common mathematical meaning (therefore
> useless in numeric computation) of inner product when provided with
> iterators whose value_types are complex<T>. It should have been
> defined as:
>
>         acc = acc + (*i1) * conj(*i2)

This can become difficult, as conj() is not defined for all types. If
you want to have this meaning for the norm of complex numbers, why not
use the second version of inner_product which takes binary operators as
parameters.

template <class InputIterator1,
          class InputIterator2,
          class T,
          class BinaryOperation1,
          class BinaryOperation2>
T inner_product(InputIterator1 first1,
                InputIterator1 last1,
                InputIterator2 first2,
                T init,
                BinaryOperation1 binary_op1,
                BinaryOperation2 binary_op2);

It's meaning is defined as
          acc = binary_op1(acc,binary_op2(*i1,*i2))

Regards,
Biju Thomas
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36364823.167E@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>> You mean you prefer to do your numerics in a language that lacks a
>> concept of value? ...
>
>OK - you've piqued my curiosity. What does that statement mean?

In Smalltalk everything is an object

In C everything is a value

In Java built-ins are values and user-defineds are objects

In C++ built-ins are values but you make your own choice for all other
types.

Each approach has its gains and losses, but you ought to know what they
are.  Smalltalk is great for many things but you need to contort your
thinking when doing numerics in it.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]