Add traits `WrappingShl` and `WrappingShr` corresponding to the
standard library `wrapping_shl` and `wrapping_shr` methods. Implement
the trait on all primitive integer types as well as on `Wrapping`.
59: Added `MulAdd` and `MulAddAssign` traits r=cuviper a=regexident
Both `f32` and `f64` implement fused multiply-add, which computes `(self * a) + b` with only one rounding error. This produces a more accurate result with better performance than a separate multiplication operation followed by an add:
```rust
fn mul_add(self, a: f32, b: f32) -> f32[src]
```
It is however not possible to make use of this in a generic context by abstracting over a trait.
My concrete use-case is machine learning, [gradient descent](https://en.wikipedia.org/wiki/Gradient_descent) to be specific,
where the core operation of updating the gradient could make use of `mul_add` for both its `weights: Vector` as well as its `bias: f32`:
```rust
struct Perceptron {
weights: Vector,
bias: f32,
}
impl MulAdd<f32, Self> for Vector {
// ...
}
impl Perceptron {
fn learn(&mut self, example: Vector, expected: f32, learning_rate: f32) {
let alpha = self.error(example, expected, learning_rate);
self.weights = example.mul_add(alpha, self.weights);
self.bias = self.bias.mul_add(alpha, self.bias)
}
}
```
(The actual impl of `Vector` would be generic over its value type: `Vector<T>`, thus requiring the trait.)
Co-authored-by: Vincent Esche <regexident@gmail.com>
Co-authored-by: Josh Stone <cuviper@gmail.com>
32: Implement CoreFloat trait r=cuviper a=vks
This is a subset of the `Float` trait, but works with `no_std`.
Some code was simplified by using `CoreFloat`.
We don't have implementations for many of the methods in `no_std`. It's
hostile to external implementors if some trait methods are conditional
on a feature, as that feature could be added by anyone in a dependency
tree. Instead, let's just live without these traits for now.
23: Add RealNum trait for real data types (Float, but without floating-point specific features) r=cuviper a=yoanlcq
This is supposed to fix [#19](https://github.com/rust-num/num-traits/issues/19); I assumed going ahead would be better than bumping the thread.
In any case, I understand that it is a quite significant addition and won't mind too much if it doesn't make it.
This adds a new `RealNum` trait, along with a universal impl `impl<T: Float> RealNum for T { ... }`.
Therefore, this shouldn't be a breaking change, except in places where both traits are imported (which obviously only happened in a few places in this crate).
The intent is that generic code may prefer to use `RealNum` instead of `Float` when floating-point isn't a requirement. In the future (next major version ?), I guess `Float` could be made to only provide floating-point-specific features on top of `RealNum`.
Most of the code+doc was copy-pasted from `Float`, but the doc comments should be up-to-date with the situation; `Float` only makes an appearance when talking about NaN and infinity.
Issues I've seen :
- `RealNum` might not be the name we want;
- I've mentioned that `sqrt()` is allowed to panic if the input is negative and has no meaningful NaN representation;
- Should we do that too for e.g `log()` ? Like `sqrt()`, it's supposed to return Nan when `x < 0`.
Thanks for your time. :)
Also update to use https instead of http. This avois mixed content
degradation on docs.rs.
The doc root URLs are correct as they are, the URL does not include the
crate name itself.
Rust 1.4 through 1.7 will issue warnings that `pub extern crate` does
not work as expected, although it appears to be fine. But Rust 1.8 and
later issue `#[warn(private_in_public)]` for `pub use num_foo as foo` if
that crate isn't public, and that's headed toward a hard error.
@bluss suggested instead `pub mod foo { pub use num_foo::*; }`, which
I thought I had tried before, but it appears to work fine on all
versions of Rust. Let's do it!
A small downside is that docs for `num::foo` now just show the wildcard
reexport, instead of direct documentation, but at least there's a link
to follow to the sub-crate.
It's a breaking change that `num::num_foo` paths are no longer public,
but we didn't really want those exposed in the first place. I consider
this minor -- people should either use the `num::foo` module as before
the split-up, or use the `num_foo` crate directly.
Fixes#189.
Serde 0.7 dropped it's dependency on num, so this patch moves
the implementations here. For the sake of a better implementation,
this just serializes BigUint as a `Vec<u32>`, `BigInt` as a
`(u8, Vec<u32>)`, `Complex<T>` as a `(T, T)`, and `Ratio<T>`
as a `(T, T)`.
Flier Lu
Ed McCardell
Josh Stone
bors[bot]
Vincent Esche
Clar Charr
Vinzent Steinberg
Yoan Lecoq
svartalf
Jacob Kiesel
bluss
Łukasz Jan Niemier
Erick Tryzelaar