Twra Sun🔴 👁 - The MAGA-Cult explained:
| GitHub | https://github.com/mattkretz |
| ORCID | https://orcid.org/0000-0002-0867-243X |
| Strava | https://www.strava.com/athletes/124318317 |
mkretz
@mkretz@floss.social
- 60 Followers
- 56 Following
- 249 Posts
👨👦👩👧👧, C++ committee numerics chair, SIMD specialist, CS PhD, Dipl.-Phys, high energy physics, former KDE core developer, FLOSS user & supporter,🏃♂️🚴♂️🏋️♂️
Christian StöckerI probably am not the only one that certainly will never travel to the US again as long as the @GOP is in power there.
The speed at which they destroy the foundations of US strength is mindboggling.
@DanielaKEngert not recoveryroad cycling but recovery roadcycling 😄
My bike must have missed me. It drove really fast through the 26–54 km/h wind. 😅
@mbr @somebody I believe that writing sqrt(a²-b²) is a bug unless there is a precondition that a and b are far enough apart or at the very least a guard against value-changing optimizations (such as FMA contraction or excess precision). So my mental model prefers a NaN, which may be easier to track down, over a -0 that hides the "bug".
But thank you. That was helpful to understand how this was motivated, even if I disagree with it.
But thank you. That was helpful to understand how this was motivated, even if I disagree with it.
And we just renamed it again. Who would have thought that we can name something 'vec' when we already have 'vector' 😅.
It'll be std::simd::vec<T, N> and std::simd::mask<T, N> in C++26.
Also vec and mask are (read-only) ranges now (range-based for works) and we got permutations, gather & scatter, compress & expand as well as mask conversions to and from bitset and unsigned. 🥳
Lot's of implementation and optimization work ahead for me now.
@somebody @mbr My mental model for -0 is a value in the range (-denorm_min, 0) and +0 in [0, denorm_min). Because -0 can only be the result of underflow. Exact zero results are always +0.
I still don't understand why you want very small negative numbers to be preserved under sqrt when all other negative numbers are not.
And of course the inconsistency still doesn't make any sense.
I still don't understand why you want very small negative numbers to be preserved under sqrt when all other negative numbers are not.
And of course the inconsistency still doesn't make any sense.
Why did IEEE specify sqrt(-0) to be -0?! That's … surprising when applied to the interpretation of -0 in the context of complex numbers:
sqrt(complex{-0,+0}) is complex{+0,+0}.
And also pow(-0, 0.5) is +0.
If anything sqrt(-0) should be NaN, but why -0?
@Methylzero @diehlpk @hpcnotes I've been asking that question since 2009, when I started doing #SIMD. It's not just GPUs where this makes a difference. FP32 is significantly more efficient on CPUs since a long time.
@Methylzero @diehlpk @hpcnotes IMHO it is not great engineering to say FP32 doesn't work but FP64 does, and since it's available that's the solution. Whenever I read code that uses FP64 there is no mention as to why something else isn't sufficient. Is it because of range, precision, or just because "I was told to default to FP64"? That's impossible to see from your typical C++ code. Would fixed-point have been a solution? Or FP32 after renormalization? Or https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic using FP32?