This is the mail archive of the
gcc@gcc.gnu.org
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 15:36:34 +0100
 Cc: gdr at codesourcery dot com (Gabriel Dos Reis), gcc at gcc dot gnu dot org, hjstein at bloomberg dot com, nbecker at fred dot net, bkoz at redhat dot com
 Organization: CodeSourcery, LLC
 References: <200111011358.fA1Dwhw18535@banach.math.purdue.edu>
Brad Lucier <lucier@math.purdue.edu> writes:
 >  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.940656e324.
 >
 > In that case, I prefer to retain the current implementation and
 > document the option. After all, nbecker can just explicitly
 > specialize for his type.

 I'm sorryI posted before working out all the issues (don't we all ;).
Certainly ;)
[...]
 There is a small group of arguments for which this
 formula gives zero when the current formula gives a nonzero result,
 but this now seems to me to be irrelevantthere are many nonzero z
 for which both formulas give zero for the norm, and the fact that
 there are a few more of these cases with the simpler formula does not
 seem important to me.
I presume we disagree on exactly where the line should be drwan. From
my point of view, I consider norm() should deliver an answer as close
as possible to the real value; that means, for nonsubnormal a value
acceptable with respect to relative error criterion, and for
subnormal, a value acceptable with respect to absolute error criterion.
Which is why I prefer to retain the current implementation for norm().
 Gaby