This is the mail archive of the
`gcc@gcc.gnu.org`
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] |

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

**References**:**Re: Change definition of complex::norm***From:*Brad Lucier

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |