Add a copysign function to f32 and f64
#55169
Conversation
This patch adds a `copysign` function to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms. I think this might work as-is, as the relevant `copysign` intrinsic is already used internally for the implementation of `signum`. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also. Part of the work towards rust-lang#55107
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
The two versions have doc comments that explain the |
I improved the f32 version and made a copy-paste error for f64.
|
Definitely, and good catch. Was just a copy-paste error. Who is a good person to look into the question of whether this might break exotic targets because llvm might generate a call to a (possibly unimplemented) library function for the general copysign intrinsic. Maybe @japaric? |
|
Instead of |
|
@nikic Good point, and I'm open to that. In this case, I'm going to suggest sticking with standard terminology, because I think the target user is much more likely to be studying or adapting numerical algorithms from other languages, rather than than writing Rust-only numerical algorithms. Also I think when studying asm output (especially wasm), it reduces the translation, understanding that But if people strongly prefer a more explicit name, I'll change it. |
|
I think keeping the standard name You could make it However, that brings to mind another thought. To prevent someone from thinking that this might modify the value in place, please add |
Added a #[must_use] annotation on copysign, per review feedback.
|
@joshtriplett Done. I agree with the rationale but will point out it's not consistent with the rest of the module. I think we can chalk that up to |
|
LGTM. If you would like to seek feedback to confirm that this will work on obscure architectures, please feel free to do so and r=me afterward. You could also go ahead, on the theory that we already use many other intrinsics and this one doesn't seem drastically less likely to work. |
|
I'm comfortable going ahead and seeing what breaks. If we get a failure on a specific architecture because of a missing |
|
@bors r+ |
|
📌 Commit f08db6b has been approved by |
bors
added
S-waiting-on-bors
Add a `copysign` function to f32 and f64 This patch adds a `copysign` function to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms. I think this might work as-is, as the relevant `copysign` intrinsic is already used internally for the implementation of `signum`. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also. Part of the work towards rust-lang#55107
Rollup of 7 pull requests Successful merges: - #54300 (Updated RELEASES.md for 1.30.0) - #55013 ([NLL] Propagate bounds from generators) - #55071 (Fix ICE and report a human readable error) - #55144 (Cleanup resolve) - #55166 (Don't warn about parentheses on `match (return)`) - #55169 (Add a `copysign` function to f32 and f64) - #55178 (Stabilize slice::chunks_exact(), chunks_exact_mut(), rchunks(), rchunks_mut(), rchunks_exact(), rchunks_exact_mut())
| /// another. | ||
| /// | ||
| /// Equal to `self` if the sign of `self` and `y` are the same, otherwise | ||
| /// equal to `-y`. If `self` is a `NAN`, then a `NAN` with the sign of `y` |
There was a problem hiding this comment.
"otherwise equal to -self", and not "-y", right? Or am I confused now?
Also: I'd rephrase the first sentence to "Returns a number composed of the magnitude of self and the sign of y". That's more explicit.
And yes, I know the PR is already merged, but I guess we should fix this in a new PR, if I'm right about this typo.
There was a problem hiding this comment.
@LukasKalbertodt You're absolutely right. I'm happy to fix this in a followup PR. Good catch!
Thanks to @LukasKalbertodt for catching this. Addresses a comment raised in rust-lang#55169 after it was merged.
…lett Fix doc for new copysign functions Thanks to \@LukasKalbertodt for catching this. Addresses a comment raised in rust-lang#55169 after it was merged.
…lett Fix doc for new copysign functions Thanks to @LukasKalbertodt for catching this. Addresses a comment raised in rust-lang#55169 after it was merged.
|
Well, it seems this is actually the tracking issue for |
|
@crlf0710 I was told on IRC that this issue could serve as the tracking issue, for such a small feature. But I am not expert on the ways of Rust stabilization. |
|
@raphlinus The tracking issue should be an issue, not a PR, i think... @Centril |
|
@crlf0710 is correct; there should be an open issue for it; take a look at https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3AT-libs for inspiration. |
|
Ok, will do. One reason I've been holding back is that was also planning on adding "round to nearest even" function as part of the same motivating work, but now I see that could take a long time (honestly, the motivation I have for it has somewhat stalled out), so no reason that should block this. |
|
Well i've just finished seeking for solutions of "round with ties to positive infinity" when i come to this issue yesterday. :) |
…Sapin
Stablize {f32,f64}::copysign().
Stablization PR for rust-lang#55169/rust-lang#58046. Please check if i'm doing it correctly. Is 1.35.0 good to go?
This patch adds a
copysignfunction to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms.I think this might work as-is, as the relevant
copysignintrinsic is already used internally for the implementation ofsignum. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also.Part of the work towards #55107