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 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 <email@example.com> 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.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.
| I'm sorry---I posted before working out all the issues (don't we all ;-).
| 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 irrelevant---there 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 non-subnormal 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().