To avoid a breaking change, these have crude default implementations as
well as better implementations for `f32` and `f64` in particular. They
don't use the inherent methods though, because `f32` didn't stabilize
those until Rust 1.7.
Fixes#211
bigint: allow `Sub` to work in-place on the RHS
A new Fibonacci benchmark demonstrates the improvement by using both
addition and subtraction in each iteration of the loop, like #200.
Before:
test fib2_100 ... bench: 4,558 ns/iter (+/- 3,357)
test fib2_1000 ... bench: 62,575 ns/iter (+/- 5,200)
test fib2_10000 ... bench: 2,898,425 ns/iter (+/- 207,973)
After:
test fib2_100 ... bench: 1,973 ns/iter (+/- 102)
test fib2_1000 ... bench: 41,203 ns/iter (+/- 947)
test fib2_10000 ... bench: 2,544,272 ns/iter (+/- 45,183)
A new Fibonacci benchmark demonstrates the improvement by using both
addition and subtraction in each iteration of the loop, like #200.
Before:
test fib2_100 ... bench: 4,558 ns/iter (+/- 3,357)
test fib2_1000 ... bench: 62,575 ns/iter (+/- 5,200)
test fib2_10000 ... bench: 2,898,425 ns/iter (+/- 207,973)
After:
test fib2_100 ... bench: 1,973 ns/iter (+/- 102)
test fib2_1000 ... bench: 41,203 ns/iter (+/- 947)
test fib2_10000 ... bench: 2,544,272 ns/iter (+/- 45,183)
This splits the main arithmetic loops from the final carry/borrow
propagation, and also normalizes the slice lengths before iteration.
This lets the optimizer generate better code for these functions.
`use serde;` leads to compilation error; `extern crate` is enough
This PR fixes the compile error of `num-complex` that appears due to a redundant `use serde;` after `extern crate serde;` in the same module. To reproduce the error, just build `num-complex` with the feature `serde`, see below.
```zsh
% cargo build --features serde
Compiling num-complex v0.1.32 (file:///home/janis/github/num/complex)
src/lib.rs:27:5: 27:10 error: an extern crate named `serde` has already been imported in this module [E0259]
src/lib.rs:27 use serde;
^~~~~
src/lib.rs:19:1: 19:20 note: previous import of `serde` here
src/lib.rs:19 extern crate serde;
^~~~~~~~~~~~~~~~~~~
src/lib.rs:27:5: 27:10 help: run `rustc --explain E0259` to see a detailed explanation
error: aborting due to previous error
error: Could not compile `num-complex`.
```
num: remove `pub` from sub-crates
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.
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.
bigint: Fix calculation of size for multiply temporaries
When x.len() and y.len() are both equal and odd, we have x1.len() + y1.len() + 1
(the required size to multiply x1 and y1) > y.len() + 1
This fixes#187
When x.len() and y.len() are both equal and odd, we have x1.len() + y1.len() + 1
(the required size to multiply x1 and y1) > y.len() + 1
This fixes#187
Added powc, powf, log and expf methods for complex numbers
I would like to have a few functions added for complex numbers (powf, log and exp function with arbitrary base). I've provided an implementation with this commit. However it requires more work and discussion and I've added comments to point out the parts which I'm especially unhappy with. Would be nice to get some feedback so that we can improve this pull request first.
Fix ToPrimitive for f64 -> f32 conversion.
Fix ToPrimitive for f64 -> f32 conversion.
It should use the destination type and not the source type to check if
the conversion would be to a value that's in range.
NOTE: A finite f64 value that is larger than the f32 value range now produces
None when converted to f32 with ToPrimitive.
Previously, too large f64 values would produce inf f32 values. This `as`
cast has an undefined result and was not specified to always produce for
example `inf`.
The conversion preserves nan/+-inf specifically.
It should use the destination type and not the source type to check if
the conversion would be to a value that's in range.
NOTE: A finite f64 value that is larger than the f32 value range now produces
None when converted to f32 with ToPrimitive.
Previously, too large f64 values would produce inf f32 values. This `as`
cast has an undefined result and was not specified to always produce for
example `inf`.
The conversion preserves nan/+-inf specifically.
Josh Stone
Homu
Kent Overstreet
Adam Crume
Richard Janis Goldschmidt
Vinzent Steinberg
Christian Liebhardt
bluss
Oliver Middleton
Łukasz Jan Niemier