| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The float modules in `std` are currently top-level but for `core`, they
are nested within the `num` directory and referenced by `#[path = ...]`.
For consistency, adjust `std` to use the same structure as `core`.
Also change the `f16` and `f128` gates from outer attributes to inner
attributes like `core` has.
|
|
When these functions were added in
https://github.com/rust-lang/rust/pull/138087
It made a relatively common pattern for emulating
these functions using an extension trait (which
internally uses `libm`) much more fragile.
If `core::f32` happened to be imported by the user
(to access a constant, say), then that import in
the module namespace would take precedence over
`f32` in the type namespace for resolving these
functions, running headfirst into the stability
attribute.
We ran into this in Color -
https://github.com/linebender/color - and chose to
release the remedial 0.3.1 and 0.2.4, to allow
downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them
into a new module should not have any long-term
concerns, and ensures that this breakage doesn't
adversely impact anyone else.
|
|
Since [1], `compiler-builtins` makes a certain set of math symbols
weakly available on all platforms. This means we can begin exposing some
of the related functions in `core`, so begin this process here.
It is not possible to provide inherent methods in both `core` and `std`
while giving them different stability gates, so standalone functions are
added instead. This provides a way to experiment with the functionality
while unstable; once it is time to stabilize, they can be converted to
inherent.
For `f16` and `f128`, everything is unstable so we can move the inherent
methods.
The following are included to start:
* floor
* ceil
* round
* round_ties_even
* trunc
* fract
* mul_add
* div_euclid
* rem_euclid
* powi
* sqrt
* abs_sub
* cbrt
These mirror the set of functions that we have in `compiler-builtins`
since [1].
Tracking issue: https://github.com/rust-lang/rust/issues/137578
[1]: https://github.com/rust-lang/compiler-builtins/pull/763
|
|
|
|
Document results of non-positive logarithms
The integer versions of logarithm functions panic on non-positive numbers. The floating point versions have different, undocumented behaviour (-inf on 0, NaN on <0). This PR documents that.
try-job: aarch64-gnu
|
|
|
|
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
|
|
|
|
Also add
```rust
// #[unstable(feature = "float_gamma", issue = "99842")]
```
to `gamma`-function-related methods on `f16` & `f128`,
as per https://github.com/rust-lang/rust/pull/136324#issuecomment-2626270247
|
|
intrinsic
|
|
Move some std tests to integration tests
Unit tests directly inside of standard library crates require a very fragile way of building that is hard to reproduce outside of bootstrap.
Follow up to https://github.com/rust-lang/rust/pull/133859
|
|
|
|
|
|
Searching "fma" in the Rust documentation returns results for
`intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add
aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add
the IEEE name to `sqrt` as well, `squareRoot`.
|
|
|
|
Some float methods are now `const fn` under the `const_float_methods` feature gate.
In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval.
|
|
|
|
|
|
|
|
Our minimum supported API version is 21, remove hacks to support older
Android APIs.
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
|
|
Same as #118217 but for `f32`.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
