3 ms·
> ('Naming: "algebraic" is not very descriptive of what this does since the operations themselves are algebraic.' :D) Okay, the floating point operations are l
by nextaccountic 1y ago
> ('Naming: "algebraic" is not very descriptive of what this does since the operations themselves are algebraic.' :D)
Okay, the floating point operations are literally algebraic (they form an algebra) but they don't follow some common algebraic properties like associativity. The linked tracking issue itself acknowledges that:
> Naming: "algebraic" is not very descriptive of what this does since the operations themselves are algebraic.
Also this comment https://github.com/rust-lang/rust/issues/136469#issuecomment-2727298355 https://github.com/rust-lang/rust/issues/136469#issuecomment...
> > On that note I added an unresolved question for naming since algebraic isn't the most clear indicator of what is going on.
>
> I think it is fairly clear. The operations allow algebraically justified optimizations, as-if the arithmetic was real arithmetic.
>
> I don't think you're going to find a clearer name, but feel free to provide suggestions. One alternative one might consider is real_add, real_sub, etc.
Then retorted here https://github.com/rust-lang/rust/issues/136469#issuecomment-2727298355 https://github.com/rust-lang/rust/issues/136469#issuecomment...
> These names suggest that the operations are more accurate than normal, where really they are less accurate. One might misinterpret that these are infinite-precision operations (perhaps with rounding after a whole sequence of operations).
>
> The actual meaning isn't that these are real number operations, it's quite the opposite: they have best-effort precision with no strict guarantees.
>
> I find "algebraic" confusing for the same reason.
>
> How about approximate_add, approximate_sub?
And the next comment
> Saying "approximate" feels imperfect, as while these operations don't promise to produce the exact IEEE result on a per-operation basis, the overall result might well be more accurate algebraically. E.g.:
>
> (...)
So there's a discussion going on about the naming
- eqvinox 1y agoIt doesn't feel appropriate to comment there for me not knowing any Rust really, but "lax_" (or "relax_") would have the extra benefit of being very short. (Is this going to overload operators or are people going to have to type this… a lot… ?)
- Sharlin 1y agoRust has some precedence for adding convenience newtypes with overloaded operators (eg. `Wrapping<I>´ for `I.wrapping_add(I)` etc). Such a wrapper isn't currently proposed AFAIK but there's no reason one couldn't be added in the future I believe.
- eqvinox 1y agoRight, as long as the LLVM intrinsics are exposed you could just put that in a crate somewhere.
- Measter 1y agoFor giggles, here's one I whipped up, along with an example use: https://godbolt.org/z/Eezj35dzc https://godbolt.org/z/Eezj35dzc
- Sharlin 1y agoWow, that's some hardcore unrolling.
- eqvinox 1y agoHaving done unspeakable things with the C preprocessor myself, this Rust macro soup truly warms my heart <3
- Measter 1y agoOh this is simple, this is just a bit of basic expansion to generate boilerplate. The real experts can do some gnarly and amazing stuff with macros.
- CryZe 1y agoWebAssembly also ended up calling its set of similar instructions relaxed.
- deleted 1y ago[deleted]