In article <363DC598.E0DDD1C6@aNOcSPAMm.org>, Jurgen Singer
<jurgen@acm.org> wrote:

> Nathan Myers wrote:
> >
> > Choosing a good name for its alternative should be left to
> > numerics (not mathematical) experts, such as any who may be
> > reading this newsgroup.  Short is good.  Choose both for what
> > you'd like to see in your own programs, and for what you wouldn't
> > like to see "used up" for other purposes.

> right: So let me suggest the name l2_norm, since this is

I would vote for magnitude_squared or modulus_squared.




[ 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:
>
> Choosing a good name for its alternative should be left to
> numerics (not mathematical) experts, such as any who may be
> reading this newsgroup.  Short is good.  Choose both for what
> you'd like to see in your own programs, and for what you wouldn't
> like to see "used up" for other purposes.
>

right: So let me suggest the name l2_norm, since this is
what we are talking about: In general the
L^p norm is defined as
   ||f||_{L^p} = ( \integral_{domain} |f(x)|^p dx )^(1/p)
while the l^p norm is defined as
   ||f||_{l^p} = ( \sum_{i=0}^n |f_i|^p )^(1/p)

The latter is therefore consistent with the usual norm for
complex numbers z = x+iy:
    ||z|| = sqrt( x^2 + y^2 )

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

"Hubert.Holin" <hubert.holin@meteo.fr> writes:

[...]

>=20
>  That is essentially because it if by far the most useful in
> applications outside the realms of mathematics (and within, as well :-)=
 =3D
>=20

So I strongly agree with Nathan's remark: the numerical part of the
library should be specified for practical purposes. =20

[...]

>=20
>  One often overlooked problem with mathematics is that any real text is
> highly context-sensitive. We differentiate when absolutely necessary (b=
y
> saying "Cayley norm" instead of just "norm"), but (almost) never to the
> point where all ambiguity is possibly resolved, only to the point where
> we believe the reader will understand what is meant.

that is what C++ called function (or operator) overloading ;-)


[...]

>=20
>  I suggest, in the case of C++, that if a defect report is produced,
> that the "norm" function either stays the same (no code will break), or
> be renamed cayley_norm, and that an euclidian_norm function be
> introduced. I believe changing the meaning of the current "norm" would
> be the worst possible solution.

That is why I made a proposal to rename "norm" as "squared_norm" or
more preferably "norm_squared" as it was suggested. But if I
understood Steve Clamage correctly, this is beyond of the scope of a
TC.=20

Maybe a TC to flag norm() deprecated ?

--=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   , Jurgen Singer <jurgen@acm.org> wrote:

> Nathan Myers wrote:
>>
>> Choosing a good name for its alternative should be left to
>> numerics (not mathematical) experts, such as any who may be
>> reading this newsgroup.  Short is good.  Choose both for what
>> you'd like to see in your own programs, and for what you wouldn't
>> like to see "used up" for other purposes.
>>

> right: So let me suggest the name l2_norm, since this is

L2_norm is not x^2 + y^2 (unless I'm mistaken we're talking about
std::norm(), right ?)


> what we are talking about: In general the
> L^p norm is defined as
>    ||f||_{L^p} = ( \integral_{domain} |f(x)|^p dx )^(1/p)
> while the l^p norm is defined as
>    ||f||_{l^p} = ( \sum_{i=0}^n |f_i|^p )^(1/p)

more precisely, this is defined on the set of all sequences u = (u_n)
such that \sum_{i=0}^{\infty} |u_i|^p is finite. And

 || u ||_{l^p} = (\sum_{i=0}^{\infty} | u_i|^p)^{1/p}


> The latter is therefore consistent with the usual norm for
> complex numbers z = x+iy:
>     ||z|| = sqrt( x^2 + y^2 )

this is already present in the standard and is named abs() -- which is
consistent with Matlab (a reference in the numerical computation area),
popular numerical textbooks.

--
Gabriel Dos Reis                   |  Centre de Math   matiques 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              ]

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

Gabriel Dos_Reis wrote:
> =

> "Hubert.Holin" <hubert.holin@meteo.fr> writes:
> =

> > Paris (U.E.), le 28/10/1998
> >
> >       I would just like to point out a minor fact: the definition of =
"norm"
> > which the C++ has chosen for complex numbers is actually correct!
> =

> In C++ norm(z) =3D=3D real(z)*real(z) + imag(z)* imag(z).
> =

> In most elementary *modern* textbooks norm(z) is defined to be the
> square root of the precedent quantity.

 That is essentially because it if by far the most useful in
applications outside the realms of mathematics (and within, as well :-) =

).

> >
> >       More precisely, this is the *Cayley* norm of the complex, and n=
ot the
> =

> Any reference?

 Bourbaki, Algebra; if I remember correctly, it is somewhere before the
definition of quaternions (which uses it).

> > *euclidian* norm of the complex, seen as an element of the real vecto=
r
> > space over the reals (Bourbaki, Algebra).
> >
> =

> Fortunately Bourbaki has become a standard reference in mathematics in
> the same way ISO C++ has become a standard reference in the C++
> community. Failing to conform to standard textbook is a royal road to
> ill-communication.

 One often overlooked problem with mathematics is that any real text is
highly context-sensitive. We differentiate when absolutely necessary (by
saying "Cayley norm" instead of just "norm"), but (almost) never to the
point where all ambiguity is possibly resolved, only to the point where
we believe the reader will understand what is meant.

 It is also nice to note that we also have the habit of putting more
than one label on the same beast, mostly for historical or political
reasons (such as calling the set of complex numbers the Argan-Cauchy
plane...).

 Boubaki also defines the norm of complex numbers as the usual euclidian
norm, and even in the same book, if memory serves, but it is felt this
should not lead to confusion (apparently this was optimistic :-)  ).

 In this case, I believe the ambiguity is due to historical reasons
(same term independently used, clash discovered long after the fact).

> >       It is unfortunate that two differing mathematical objects share=
 the
> > same name, but it is also why one has to pay attention to the context=

> > (and use namespaces :-)    ).
> =

> But norm() is Cayley sense is *not* the standard definition of
> norm. Right?

 For most intents and purposes, no.

 I suggest, in the case of C++, that if a defect report is produced,
that the "norm" function either stays the same (no code will break), or
be renamed cayley_norm, and that an euclidian_norm function be
introduced. I believe changing the meaning of the current "norm" would
be the worst possible solution.

> --
> 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


  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              ]

Hubert.Holin<Hubert.Holin@bigfoot.com> wrote:
>Gabriel Dos_Reis wrote:
>> But norm() is Cayley sense is *not* the standard definition of
>> norm. Right?
>
> For most intents and purposes, no.
>
> I suggest, in the case of C++, that if a defect report is produced,
>that the "norm" function either stays the same (no code will break), or
>be renamed cayley_norm, and that an euclidian_norm function be
>introduced. I believe changing the meaning of the current "norm" would
>be the worst possible solution.

This is the most likely approach to appeal to committee members
as well.  Breaking code in a way that offers no clear indication
that it's been broken is considered a Bad Thing (tm).  The name
"norm" might be deprecated, but as such it will probably keep
the current definition, though being deprecated, implementations
will be encouraged to warn about its use.

Choosing a good name for its alternative should be left to
numerics (not mathematical) experts, such as any who may be
reading this newsgroup.  Short is good.  Choose both for what
you'd like to see in your own programs, and for what you wouldn't
like to see "used up" for other purposes.

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

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

 I would just like to point out a minor fact: the definition of "norm"
which the C++ has chosen for complex numbers is actually correct!

 More precisely, this is the *Cayley* norm of the complex, and not the
*euclidian* norm of the complex, seen as an element of the real vector
space over the reals (Bourbaki, Algebra).

 It is unfortunate that two differing mathematical objects share the
same name, but it is also why one has to pay attention to the context
(and use namespaces :-)    ).

  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              ]

"Hubert.Holin" <hubert.holin@meteo.fr> writes:

> Paris (U.E.), le 28/10/1998
>=20
>  I would just like to point out a minor fact: the definition of "norm"
> which the C++ has chosen for complex numbers is actually correct!

In C++ norm(z) =3D=3D real(z)*real(z) + imag(z)* imag(z).

In most elementary *modern* textbooks norm(z) is defined to be the
square root of the precedent quantity.

>=20
>  More precisely, this is the *Cayley* norm of the complex, and not the

Any reference?

> *euclidian* norm of the complex, seen as an element of the real vector
> space over the reals (Bourbaki, Algebra).
>=20

Fortunately Bourbaki has become a standard reference in mathematics in=20
the same way ISO C++ has become a standard reference in the C++
community. Failing to conform to standard textbook is a royal road to
ill-communication.=20

>  It is unfortunate that two differing mathematical objects share the
> same name, but it is also why one has to pay attention to the context
> (and use namespaces :-)    ).

But norm() is Cayley sense is *not* the standard definition of
norm. Right?=20

--=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              ]

In article fsf@korrigan.inria.fr, Gabriel Dos_Reis <gdosreis@sophia.inria.fr> writes:
>
>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.

More precisely, anyone can propose a defect report. The committee
evaluates submitted defect reports and eventually issues Technical
Corrigenda. A TC cannot make significant changes in the standard;
it can clarify ambiguous wording or correct contradictory statements.
Changing the name of or making incompatible changes in semantics of
an existing function is outside the scope of a TC. Adding things
to the standard is also outside the scope of a TC.

The next opportunity for changing the meaning of existing functions
or adding new functions will be when the standard comes up for
review and change. That will be not sooner than the year 2003.

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

That's pretty much true. We attempted to get numerical experts onto
the committee without much success. We had one expert for a time
who was responsible for most of valarray. His employer withdrew
support for his continuing committee work, and he had to withdraw.

---
Steve Clamage, stephen.clamage@sun.com
---
[ 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              ]