This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: std::norm improvement


On Wed, 4 Mar 2009, Andrew Pinski wrote:

" Still, I think
gcc is pointlessly (is that an English word?) decreasing performance
if ffast-math is not on (it's not on even with -O3).
"

No it is not, this is the problem here. That is from the thread you
wrote in.  You did not test every single input to figure out if your
implementation is better or worse.  I think it might be best if you
tested every input include NaNs and infs.  That is where some problems
come into play also I think.

Remember that a NaN input should result in a NaN result.

For NaN, it is probably enough to call min(x,y) and max(y,x) in his code in order to be sure that at least one is still a NaN (unless you want norm(NaN,Inf) to be +Inf, but the current implementation doesn't do it either, and I am not sure it is even legal).


For infs, the current implementation (when there is no C99 complex function) uses a inf/inf division and should thus return a NaN whereas we would expect a +Inf. (an implementation that uses 1 instead of (max/max)^2 would get this right except when both the real and imaginary parts are infinite, as does his implementation I believe)

The case that seems to have justified the current implementation (and his seems to be doing ok there) instead of the trivial one is when x^2 and y^2 are both small enough to be computed as 0 but their sum is not.

--
Marc Glisse


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