about summary refs log tree commit diff
path: root/library/std/src/f32.rs
AgeCommit message (Collapse)AuthorLines
2023-03-07Auto merge of #95317 - Jules-Bertholet:round_ties_to_even, ↵bors-0/+30
r=pnkfelix,m-ou-se,scottmcm Add `round_ties_even` to `f32` and `f64` Tracking issue: #96710 Redux of #82273. See also #55107 Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this. Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`). Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight. Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
2023-02-05Clarify wording on f64::round() and f32::round()Wilfred Hughes-2/+2
"Round half-way cases" is a little confusing (it's a 'garden path sentence' as it's not immediately clear whether round is an adjective or verb). Make this sentence longer and clearer.
2022-12-11Remove some `cfg(not(bootstrap))`Jules Bertholet-2/+1
2022-12-11Use rint instead of roundevenJules Bertholet-1/+1
Use rint intrinsic instead of roundeven to impement `round_ties_even`. They do the same thing when rounding mode is default, which Rust assumes. And `rint` has better platform support. Keeps `roundeven` around in `core::intrinsics`, it's doing no harm there.
2022-12-11Add tracking issueJules Bertholet-1/+1
2022-12-11Add `round_ties_even` to `f32` and `f64`Jules Bertholet-0/+31
2022-11-17Improve accuracy of asinh and acoshMax Willsey-2/+8
2022-11-06rustdoc: Add an example for round that is different from truncateyancy-0/+2
2022-11-04Small round of typo fixesAlex Saveau-1/+1
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2022-08-20Improve primitive/std docs separation and headersCameron Steffen-1/+1
2022-05-09Rollup merge of #95483 - golddranks:improve_float_docs, r=joshtriplettMatthias Krüger-11/+15
Improve floating point documentation This is my attempt to improve/solve https://github.com/rust-lang/rust/issues/95468 and https://github.com/rust-lang/rust/issues/73328 . Added/refined explanations: - Refine the "NaN as a special value" top level explanation of f32 - Refine `const NAN` docstring: add an explanation about there being multitude of NaN bitpatterns and disclaimer about the portability/stability guarantees. - Refine `fn is_sign_positive` and `fn is_sign_negative` docstrings: add disclaimer about the sign bit of NaNs. - Refine `fn min` and `fn max` docstrings: explain the semantics and their relationship to the standard and libm better. - Refine `fn trunc` docstrings: explain the semantics slightly more. - Refine `fn powi` docstrings: add disclaimer that the rounding behaviour might be different from `powf`. - Refine `fn copysign` docstrings: add disclaimer about payloads of NaNs. - Refine `minimum` and `maximum`: add disclaimer that "propagating NaN" doesn't mean that propagating the NaN bit patterns is guaranteed. - Refine `max` and `min` docstrings: add "ignoring NaN" to bring the one-row explanation to parity with `minimum` and `maximum`. Cosmetic changes: - Reword `NaN` and `NAN` as plain "NaN", unless they refer to the specific `const NAN`. - Reword "a number" to `self` in function docstrings to clarify. - Remove "Returns NAN if the number is NAN" from `abs`, as this is told to be the default behavior in the top explanation.
2022-05-02Fix nitsPyry Kontio-1/+1
2022-04-14Remove use of `#[rustc_deprecated]`Jacob Pratt-8/+8
2022-04-05trivial cfg(bootstrap) changesPietro Albini-40/+39
2022-03-31Improve floating point documentation:Pyry Kontio-11/+15
- Refine the "NaN as a special value" top level explanation of f32 - Refine `const NAN` docstring. - Refine `fn is_sign_positive` and `fn is_sign_negative` docstrings. - Refine `fn min` and `fn max` docstrings. - Refine `fn trunc` docstrings. - Refine `fn powi` docstrings. - Refine `fn copysign` docstrings. - Reword `NaN` and `NAN` as plain "NaN", unless they refer to the specific `const NAN`. - Reword "a number" to `self` in function docstrings to clarify. - Remove "Returns NAN if the number is NAN" as this is told to be the default behavior in the top explanation. - Remove "propagating NaNs", as full propagation (preservation of payloads) is not guaranteed.
2022-03-30remove now unnecessary lang itemslcnr-1/+1
2022-03-30rework implementation for inherent impls for builtin typeslcnr-0/+39
2021-10-25Remove fNN::lerp - consensus unlikelyCAD97-36/+0
2021-07-29Fix may not to appropriate might not or must notAli Malik-1/+1
2021-07-07Clarify behaviour of f64 and f32::sqrt when argument is negative zerocyberia-1/+3
2021-06-13Change tracking issueltdk-1/+1
2021-06-13More lerp tests, altering lerp docsltdk-13/+21
2021-06-01Add lerp methodltdk-0/+28
2021-02-26doc: cube root, not cubic rootTrevor Spiteri-1/+1
Like we say square root, not quadratic root.
2021-01-20Deprecate-in-future the constants superceded by RFC 2700bstrie-13/+10
2020-12-19Auto merge of #79473 - m-ou-se:clamp-in-core, r=m-ou-sebors-35/+0
Move {f32,f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`), the versions for the `f32` and `f64` primitives were added in `std` (together with `floor`, `sin`, etc.), not in `core` (together with `min`, `max`, `from_bits`, etc.). This change moves them to `core`, such that `clamp` on floats is available in `no_std` programs as well.
2020-12-10Rollup merge of #77027 - termhn:mul_add_doc_change, r=m-ou-seTyler Mandry-2/+4
Improve documentation for `std::{f32,f64}::mul_add` Makes it more clear that performance improvement is not guaranteed when using FMA, even when the target architecture supports it natively.
2020-11-27Move {f32,f64}::clamp to core.Mara Bos-35/+0
2020-11-22Auto merge of #77872 - Xaeroxe:stabilize-clamp, r=scottmcmbors-2/+1
Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?
2020-11-20We missed 1.49.0, so bump version to 1.50.0Jacob Kiesel-1/+1
2020-10-31Rollup merge of #77099 - tspiteri:exp_m1-examples, r=m-ou-seMara Bos-8/+10
make exp_m1 and ln_1p examples more representative of use With this PR, the examples for `exp_m1` would fail if `x.exp() - 1.0` is used instead of `x.exp_m1()`, and the examples for `ln_1p` would fail if `(x + 1.0).ln()` is used instead of `x.ln_1p()`.
2020-10-29Improve wording of `core::ptr::drop_in_place` docsCamelid-1/+1
And two small intra-doc link conversions in `std::{f32, f64}`.
2020-10-13generalize warningGray Olson-4/+3
2020-10-12Stabilize clampJacob Kiesel-2/+1
2020-09-23make ln_1p examples more representative of useTrevor Spiteri-4/+5
With this commit, the examples for ln_1p would fail if (x + 1.0).ln() is used instead of x.ln_1p().
2020-09-23make exp_m1 examples more representative of useTrevor Spiteri-4/+5
With this commit, the examples for exp_m1 would fail if x.exp() - 1.0 is used instead of x.exp_m1().
2020-09-21Edit documentation for `std::{f32,f64}::mul_add`.Gray Olson-2/+5
Makes it more clear that a performance improvement is not guaranteed when using FMA, even when the target architecture supports it natively.
2020-08-31std: move "mod tests/benches" to separate filesLzu Tao-763/+3
Also doing fmt inplace as requested.
2020-07-27mv std libs to library/mark-0/+1674
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 07:35:59 +0000