3 ms·
I suspect that statement is not true for floats. Possibly you don’t get the same float from min(0,-0) as min(-0,0), and similarly with NaNs. Rust specifies that
by dan-robertson 7y ago
I suspect that statement is not true for floats. Possibly you don’t get the same float from min(0,-0) as min(-0,0), and similarly with NaNs. Rust specifies that if one input is NaN then the other is returned but doesn’t say what happens if both are NaN.
- gpm 7y agoHmm, not sure what the llvm semantics look like, but you're right about the assembly semantics, vminsd (the instruction used in the post) is unfortunately not symettric in it's handling on NaN. https://www.felixcloutier.com/x86/minsd https://www.felixcloutier.com/x86/minsd
- londons_explore 7y agoNaN's are rarely required on the fast path of any code... The compiler ought to make a 2nd slow implementation for if any NaNs are seen.
- fluffything 7y agoSure, but then it needs to add a branch to detect the inputs, and maybe keep around some state to switch between implementations at run-time. Its far from clear that doing that is, in general, worth it.
- fluffything 7y ago> Rust specifies that if one input is NaN then the other is returned but doesn’t say what happens if both are NaN. It does. If both are NaN a NaN is returned. Note, however, that when Rust says that a NaN is returned, this means that any NaN can be returned. So if you have min(NaN0, NaN0) the result isn't necessarily NaN0, it might be another NaN with a different payload.
- dan-robertson 7y agoRight. That’s what I was getting at but I didn’t know the NaN-return rule.