Re: Change definition of complex::norm

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Brad Lucier <lucier@math.purdue.edu> 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
where possible.

[...]

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

OK.

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

-- Gaby