This is the mail archive of the
mailing list for the GCC project.
Re: Change definition of complex::norm
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Subject: Re: Change definition of complex::norm
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 01 Nov 2001 07:00:34 +0100
- Cc: gcc at gcc dot gnu dot org, hjstein at bloomberg dot com, nbecker at fred dot net, gdr at codesourcery dot com, bkoz at redhat dot com
- Organization: CodeSourcery, LLC
- References: <200111010245.fA12jbk17021@banach.math.purdue.edu>
Brad Lucier <firstname.lastname@example.org> writes:
| I've done a bit of investigation, and can offer some information
| and suggestions, but someone else will need to generate the patch,
| as I know very little about this part of C++.
| First, I find the following statement in the standard:
| > 26.2 Complex numbers [lib.complex.numbers]
| > ...
| > 2 The effect of instantiating the template complex for any type other than
| > float, double or long double is unspecified.
| Point (2) seems to turn the issue of implementation of <complex> templates
| and operations for, e.g., int or long, into a QOI issue.
Yes, this was already discussed. And I agreed that we should make it
possible for type other than floa, double and long double to be used
| The results are the same on sparc-sun-solaris28 and i686-pc-linux-gnu:
| [lucier@curie ~]$ ./test
| abs_1: 1.694881e+308
| abs_2: nan
| norm_1: 0.000000e+00
| norm_2: 4.940656e-324
| abs_2 uses the algorithm in std_complex.h; abs_1 uses the max of
| the absolute values of x and y as the divisor. Getting a NaN
| when the proper answer is finite is not a "Good Thing", so I think
| that the definition in std_complex.h should be changed.
| norm_2 uses the definition in std_complex.h (with the fixed abs, i.e.,
| abs_1). norm_1 uses the simpler, faster, algorithm for norm proposed
| by nbecker. Here, the simpler algorithm gives an anwer that loses
| all precision. On the other hand, I can't judge how important it
| is that a simpler, faster, algorithm gives 0.0 as the answer instead
| of 4.940656e-324.
In that case, I prefer to retain the current implementation and
document the option. After all, nbecker can just explicitly
specialize for his type.