Add a trait for floating-point constants
The pull request is to address issue #194. In order to keep the library organized, I’ve introduced a new trait for the new functionality. The trait is supposed to closely follows the [`consts`](https://doc.rust-lang.org/std/f64/consts/index.html) module from the standard library. There are at least the following three open questions:
1. What should the name of the trait be? Currently, it’s `Constant`; an alternative is `Consts`.
2. What should the names of the getters be? Currently, they are lower-case versions of the constants defined in the `consts` module. Note that `Float` provides `log2` and `log10`, whereas `LOG_2` and `LOG_10` get translated into `log_2` and `log_10`, respectively.
3. Should `Float` require the new trait? Or should it be left up to the user?
Please let me know what you think. Thank you!
Regards,
Ivan
Inline small functions, especially wrappers
We already had `#[inline]` throughout a lot of the code, but notably some
functions which simply wrap inherent methods were not inlined. That means
external references will get a full function call, when they could have been
optimized to as little as one opcode.
This PR inlines all functions that look tiny enough for this to matter.
Fixes#218.
rational: recip bugfix and documentation tweaks
Cherry picked from #210 (minus the `new_raw` stuff), with small additions [in a third commit](32dee9a0c8).
traits: add `to_degrees` and `to_radians` on `Float`
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
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.
Homu
Richard Janis Goldschmidt
Ivan Ukhov
Josh Stone
Michael Lamparski
Kent Overstreet
Adam Crume
Vinzent Steinberg