[orlp]

I don't believe so, no. Currently these operations only set the LLVM flags to allow reassociation, contraction, division replaced by reciprocal multiplication, and the assumption of no signed zeroes.

This can be expanded in the future as LLVM offers more flags that fall within the scope of algebraically motivated optimizations.

[eqvinox]

Ah sorry I misunderstood and thought this API was for the other way around, i.e. forbidding "unsafe" operations. (I guess the question reverses to setting those flags)

('Naming: "algebraic" is not very descriptive of what this does since the operations themselves are algebraic.' :D)

[nextaccountic]

> ('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...

> > 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...

> 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]

It 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]

Rust 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.

[Measter]

For giggles, here's one I whipped up, along with an example use: https://godbolt.org/z/Eezj35dzc

[eqvinox]

Having done unspeakable things with the C preprocessor myself, this Rust macro soup truly warms my heart <3

[Sharlin]

Wow, that's some hardcore unrolling.

[eqvinox]

Right, as long as the LLVM intrinsics are exposed you could just put that in a crate somewhere.

[CryZe]

WebAssembly also ended up calling its set of similar instructions relaxed.