Hubert HOLIN <Hubert.Holin@meteo.fr> writes:

| Somewhere in the E.U., le 30/05/2001
|
| Gabriel Dos Reis wrote:
| >
| > Hubert HOLIN <Hubert.Holin@Bigfoot.com> writes:
| >
| > | Paris (U.E.), le 28/05/2001
| > |
| > |       The last free draft of the standard (the only one I have >-| ) is
| > | rather dry on fringe behaviour of some functions defined on complex numbers.
| > |
| > |       For instance, if a system says that numeric_limits<T>::has_infinity()
| > | is true, and if z is a complex with a zero imaginary part (so it
| > | actually is real ;-)  ) and a real part which is close to
| > | numeric_limits<T>.infinity() but still a valid representable number,
| > | what should norm(z) be? numeric_limits<T>.infinity() ? Implementation-defined?
| >
| > First it should be noted that norm(const complex<T>&) is a misnommer
| > and that practice should not be perpetuated -- it does not correspond
|
|   I disagree.

You're welcome. The technical reasons for your disagreement are,
however, missing.

| > to any *numerical* practice even though you can find something called
| > "norm()" defined on gaussian integers, but then the standard
|
|   Cayley Norm, shared also by quaternions, octonions and other such beasts...

I know well very the Algebra in question, thanks.

The precise name varies from one manual to another; and is actual
irrevelant to the fact that what the standard names std::norm() has
nothing to do what is defined as a "norm" in standard numerical texts.
We gain nothing but obfuscation by misnaming usual abstractions.

| > explicitly says that the effect of instanting std::complex<> on
| > integer types is unspecified.  squared_norm() is a better name.
|
| [SNIP]
|
|   Well, some aspects may (rightly) be unspecified, such are taking the
| sin of an arbitrary complex<int>, but that does not mean this is
| completely useless.

Did anyone say that is useless?

|   As for "squared_norm", then just no. squared_euclidian_norm or

When talking of a euclidian space, it is practically redundant to say
one is using a euclidian norm.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Somewhere in the E.U., le 30/05/2001

Gabriel Dos Reis wrote:
>
> Hubert HOLIN <Hubert.Holin@Bigfoot.com> writes:
>
> | Paris (U.E.), le 28/05/2001
> |
> |       The last free draft of the standard (the only one I have >-| ) is
> | rather dry on fringe behaviour of some functions defined on complex numbers.
> |
> |       For instance, if a system says that numeric_limits<T>::has_infinity()
> | is true, and if z is a complex with a zero imaginary part (so it
> | actually is real ;-)  ) and a real part which is close to
> | numeric_limits<T>.infinity() but still a valid representable number,
> | what should norm(z) be? numeric_limits<T>.infinity() ? Implementation-defined?
>
> First it should be noted that norm(const complex<T>&) is a misnommer
> and that practice should not be perpetuated -- it does not correspond

  I disagree.

> to any *numerical* practice even though you can find something called
> "norm()" defined on gaussian integers, but then the standard

  Cayley Norm, shared also by quaternions, octonions and other such beasts...

> explicitly says that the effect of instanting std::complex<> on
> integer types is unspecified.  squared_norm() is a better name.

[SNIP]

  Well, some aspects may (rightly) be unspecified, such are taking the
sin of an arbitrary complex<int>, but that does not mean this is
completely useless. The arithmetic portion of the complex class is
already interesting. Though I agree it would be better that another
class bore the responsability of the complex<int> algebraic behaviour
(and besides, it would require more template parameters ;-)  ).

  As for "squared_norm", then just no. squared_euclidian_norm or
squared_l2_norm if you wish. I also believe the sup norm (a.k.a. l
infinite norm) and the l1 norm should be provided for complexes in the standard.

   Hubert Holin
   Hubert.Holin@Bigfoot.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://www.research.att.com/~austern/csc/faq.html                ]

Somewhere in the E.U., le 30/05/2001

"James Kuyper Jr." wrote:
>=20
> Hubert HOLIN wrote:

[SNIP]

> C doesn't have the (mis-named) norm() function defined by C++; therefor=
e
> the case you're worried about doesn't come up in C.

  I would not say "norm" is mis-named, only unfortunately-named. This is
indeed the Cayley Norm of the complex number. This has almost nothing to
do with the notion of a norm as defined on a vector space. In the case
of complexes (and quaternions and octonions), the present definition
could be claimed to have precedence. But of course, this is a really
tiny nit to pick.

> The C standard has a much more detailed handling of this. The C99
> standard introduced 3 standard-defined #pragmas for first time, and
> reserved for future use all #pragmas starting with "STDC ". #pragma STD=
C
> CX_LIMITED_RANGE ON makes it legal from that point on, for the
> implementation to use the "naive" formulas for complex arithmetic, even
> though those formulas will can cause unnecessary loss of precision, and
> undue overflow or underflow. #pragma STDC CX_LIMITED_RANGE_OFF requires
> the use of safer methods, which are inherently slightly slower. Note:
> there's no way to force the use of the simple formulas, there's only a
> way to indicate that they're allowed. Appendix G gives example C code
> for an IEC 60559-compatible implementation of complex multiplication an=
d
> division, including correct handling of NaNs and infinities.

  Is the content of that appendix the same (essentially) as that of
document "n620.pdf" (Complex Arithmetic Edits=97Update; WG14/N620
X3J11/96-84 (Draft 10/15/96); Jim Thomas)?

  This raises another question. The C++ standard includes by reference
an older (now) C standard and lists the headers it borrows from that
language. But does not list extensively the *content* of those headers
(for that matter it does not actually list the content of the headers it
itself introduces...). Now the C standard has changed, presumably the
content of these (borrowed) headers have as well. How can one reasonably
know if something used from one of these headers is iso-C++ compliant?

  Case in point: is "isinf" part of the C++ standard (by reference) or
not? Is it a function (::std::isinf?), or a macro?

  In preparation for the renewal of the C++ standard, I believe we
should be fully explicit so as to avoid such (perceived?) ambiguities.
Without, of course, incorporating verbatim the reference standard...

   Hubert Holin
   Hubert.Holin@Bigfoot.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://www.research.att.com/~austern/csc/faq.html                ]

> "Hubert HOLIN" <Hubert.Holin@meteo.fr> wrote in message
> news:3B14E457.1C73764B@meteo.fr...
> Somewhere in the E.U., le 30/05/2001

> Case in point: is "isinf" part of the C++ standard (by reference) or
> not? Is it a function (::std::isinf?), or a macro?

It's not. The reference in the C++ Standard is to C90, as amended in
1995. Our C99 library does play well with our C++ library, but we had
to do some creative interpolation to bridge the gap.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.research.att.com/~austern/csc/faq.html                ]

Hubert HOLIN wrote:
>
> Paris (U.E.), le 28/05/2001
>
>         The last free draft of the standard (the only one I have >-| ) is
> rather dry on fringe behaviour of some functions defined on complex numbers.
>
>         For instance, if a system says that numeric_limits<T>::has_infinity()
> is true, and if z is a complex with a zero imaginary part (so it
> actually is real ;-)  ) and a real part which is close to
> numeric_limits<T>.infinity() but still a valid representable number,
> what should norm(z) be? numeric_limits<T>.infinity() ? Implementation-defined?

26.2p3: "If the result of a function is not mathematically defined or
not in the range of representable values for its type, the behavior is
undefined."

If a given type has_inifinity(), then the value is NOT outside the
representable range, and it should therefore return infinity().

>         In a like vein, abs(z) may be a perfectly reasonable number, but
> "naive" computation (a*a+b*b) may overflow. Is abs allowed to return a
> nonsensical result in this case? QoI?

Technically, it's allowed to fail only when the result cannot be
represented. There are well-known techniques for achieving this result,
but they carry a certain amount of cost. You can be fairly certain that
there are low-quality implementations out there that don't use them. I
wouldn't consider them conforming, but they'd probably claim that they
are.

>         What does the actual standard say, if anything, about these questions?
> For that matter, what does the latest C standard (which I believe also
> has complex numbers) say about that?

C doesn't have the (mis-named) norm() function defined by C++; therefore
the case you're worried about doesn't come up in C.

The C standard has a much more detailed handling of this. The C99
standard introduced 3 standard-defined #pragmas for first time, and
reserved for future use all #pragmas starting with "STDC ". #pragma STDC
CX_LIMITED_RANGE ON makes it legal from that point on, for the
implementation to use the "naive" formulas for complex arithmetic, even
though those formulas will can cause unnecessary loss of precision, and
undue overflow or underflow. #pragma STDC CX_LIMITED_RANGE_OFF requires
the use of safer methods, which are inherently slightly slower. Note:
there's no way to force the use of the simple formulas, there's only a
way to indicate that they're allowed. Appendix G gives example C code
for an IEC 60559-compatible implementation of complex multiplication and
division, including correct handling of NaNs and infinities.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Hubert HOLIN <Hubert.Holin@Bigfoot.com> writes:

| Paris (U.E.), le 28/05/2001
|
|  The last free draft of the standard (the only one I have >-| ) is
| rather dry on fringe behaviour of some functions defined on complex numbers.
|
|  For instance, if a system says that numeric_limits<T>::has_infinity()
| is true, and if z is a complex with a zero imaginary part (so it
| actually is real ;-)  ) and a real part which is close to
| numeric_limits<T>.infinity() but still a valid representable number,
| what should norm(z) be? numeric_limits<T>.infinity() ? Implementation-defined?

First it should be noted that norm(const complex<T>&) is a misnommer
and that practice should not be perpetuated -- it does not correspond
to any *numerical* practice even though you can find something called
"norm()" defined on gaussian integers, but then the standard
explicitly says that the effect of instanting std::complex<> on
integer types is unspecified.  squared_norm() is a better name.

Now, if z.real() is too close to numeric_limits<T>::infinity() so that
its square is not representable then you get an overflow.
>From standard C++ point of view, you have an undefined behaviour.
However, an implementation can choose to adhere to IEC-559 or
LIA-1. In the latter case, an exception could be thrown.  The C++
standard says nothing on the matter.

|  In a like vein, abs(z) may be a perfectly reasonable number, but
| "naive" computation (a*a+b*b) may overflow. Is abs allowed to return a
| nonsensical result in this case? QoI?

It should return a sensical result because the standard doesn't say
how the results are computed; it merely says the effect. So if abs(z)
is representable, then the implementation should take the appropriate
steps to deliver sensical results.  I think that is the least one can
expect.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

| Hubert HOLIN wrote:
| >
| > Paris (U.E.), le 28/05/2001
| >
| >         The last free draft of the standard (the only one I have >-| ) is
| > rather dry on fringe behaviour of some functions defined on complex numbers.
| >
| >         For instance, if a system says that numeric_limits<T>::has_infinity()
| > is true, and if z is a complex with a zero imaginary part (so it
| > actually is real ;-)  ) and a real part which is close to
| > numeric_limits<T>.infinity() but still a valid representable number,
| > what should norm(z) be? numeric_limits<T>.infinity() ? Implementation-defined?
|
| 26.2p3: "If the result of a function is not mathematically defined or
| not in the range of representable values for its type, the behavior is
| undefined."
|
| If a given type has_inifinity(), then the value is NOT outside the
| representable range, and it should therefore return infinity().

Do you have references to chapters and verses to support that statement?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
...
> undue overflow or underflow. #pragma STDC CX_LIMITED_RANGE_OFF requires

Correction: #pragma STDC CX_LIMITED_RANGE OFF

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Paris (U.E.), le 28/05/2001

 The last free draft of the standard (the only one I have >-| ) is
rather dry on fringe behaviour of some functions defined on complex numbers.

 For instance, if a system says that numeric_limits<T>::has_infinity()
is true, and if z is a complex with a zero imaginary part (so it
actually is real ;-)  ) and a real part which is close to
numeric_limits<T>.infinity() but still a valid representable number,
what should norm(z) be? numeric_limits<T>.infinity() ? Implementation-defined?

 In a like vein, abs(z) may be a perfectly reasonable number, but
"naive" computation (a*a+b*b) may overflow. Is abs allowed to return a
nonsensical result in this case? QoI?

 What does the actual standard say, if anything, about these questions?
For that matter, what does the latest C standard (which I believe also
has complex numbers) say about that?

  Hubert Holin
  Hubert.Holin@Bigfoot.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://www.research.att.com/~austern/csc/faq.html                ]