| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Name what ln_gamma does
The previous description omitted some important details.
|
|
This is what the function is called in several other languages:
* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/log1p
* https://numpy.org/doc/stable/reference/generated/numpy.log1p.html
* https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/log1p-log1pf-log1pl2?view=msvc-170
It also confused people at URLO: https://users.rust-lang.org/t/64-bit-trigonometry/98599/27
|
|
Add `modulo` and `mod` as doc aliases for `rem_euclid`.
When I was learning Rust I looked for “a modulo function” and couldn’t find one, so thought I had to write my own; it wasn't at all obvious that a function with “rem” in the name was the function I wanted. Hopefully this will save the next learner from that.
However, it does have the disadvantage that the top results in rustdoc for “mod” are now these aliases instead of the Rust keyword, which probably isn't ideal.
|
|
When I was learning Rust I looked for “a modulo function” and couldn’t
find one, so thought I had to write my own; it wasn't at all obvious
that a function with “rem” in the name was the function I wanted.
Hopefully this will save the next learner from that.
However, it does have the disadvantage that the top results in rustdoc
for “mod” are now these aliases instead of the Rust keyword, which
probably isn't ideal.
|
|
These are common alternate names, usually a less-abbreviated form,
for the operation; e.g. `arctan` instead of `atan`. Prompted by
<https://users.rust-lang.org/t/64-bit-trigonometry/98599>
|
|
The previous description omitted some important details.
|
|
|
|
|
|
|
|
Re-phrase in a way that handles input values being either 0 or
negative.
|
|
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`?
|
|
"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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
|
|
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.
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Like we say square root, not quadratic root.
|
|
|
|
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.
|
|
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.
|
|
|
|
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?
|
|
|
|
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()`.
|
|
Improve wording of `core::ptr::drop_in_place` docs
And two small intra-doc link conversions in `std::{f32, f64}`.
|
|
And two small intra-doc link conversions in `std::{f32, f64}`.
|
|
Signed-off-by: wcampbell <wcampbell1995@gmail.com>
|
|
|
|
|
|
With this commit, the examples for ln_1p would fail if (x + 1.0).ln()
is used instead of x.ln_1p().
|
|
With this commit, the examples for exp_m1 would fail if x.exp() - 1.0
is used instead of x.exp_m1().
|
|
Makes it more clear that a performance improvement is not guaranteed
when using FMA, even when the target architecture supports it natively.
|
|
Also doing fmt inplace as requested.
|
