This is the mail archive of the
mailing list for the libstdc++ project.
Re: [v3] Possible fix for PR 5730
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jerry Quinn <jlquinn at optonline dot net>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: 19 Mar 2003 15:16:24 +0100
- Subject: Re: [v3] Possible fix for PR 5730
- Organization: Integrable Solutions
- References: <E18veFm-0003IA-00@tiamat>
Jerry Quinn <jlquinn at optonline dot net> writes:
| I just tried the test case comparing gcc 2.95 and 3.3 branch. The gap is now
| smaller than the reporter saw, but it is there:
| gcc 2.95 1.2s
| gcc 3.3 1.6s
| Can someone that actually understands floating point explain the accuracy
| improvement with the current implementation? Mathematically (ignoring fp
| limitations), they are equivalent. So how does the distinction show up with
| actual fp math?
| Anyway, I thought that if the more accurate answer is required, the faster
| solution could still be used under --fast-math. Opinions?
I would prefer we do not duplicate code but use something along the line:
norm(const complex<_Tp>& __z)
return _Norm_helper<__FAST_MATH__ || __is_floating<_Tp>::_M_type>
Now, I realize the macro __FAST_MATH__ may not be defined with
definite value -- that is really sad.
Then maybe we want to add this to the config file
# define _GLIBCPP_FAST_MATH 1
# define _GLIBCPP_FAST_MATH 0
and use _GLIBCPP_FAST_MATH.