This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Change definition of complex::norm

Brad Lucier <> 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 ;-).

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

-- Gaby

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]