rational: test_recip_fail: Correct should_panic syntax
Fixes this warning with rustc nightly:
```
warning: attribute must be of the form: `#[should_panic]` or `#[should_panic(expected = "error message")]`
--> rational/src/lib.rs:1051:7
|
1051 | #[should_panic = "== 0"]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: Errors in this attribute were erroneously allowed and will become a hard error in a future release.
```
Fixes this warning:
warning: attribute must be of the form: `#[should_panic]` or `#[should_panic(expected = "error message")]`
--> rational/src/lib.rs:1051:7
|
1051 | #[should_panic = "== 0"]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: Errors in this attribute were erroneously allowed and will become a hard error in a future release.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
rational: Into<(T,T)> implementation
Right now it appears impossible to get integers without cloning them. Converting into a pair can be a cheap and easy way to extract the data.
Added trait From<T> for Ratio<T> where T: Clone + Integer
Hi!
So I thought that this kind of trait would be useful when one wants to write code which should be generic over different types of numbers.
Add doc(html_root_url) and other doc attrs to each crate
Also update to use https instead of http. This avoids mixed content
degradation on docs.rs.
The doc root URLs are correct as they are, the URL does not include the
crate name itself.
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.
traits: Remove pattern in trait's method signature
This use of `mut` was nonsensical for now, but is proposed to be
disallowed by rustc in the future (as a bugfix).
See rust-lang/rust/pull/37378 for context.
Implementing epsilon function to retrieve EPSILON constant
Hey!
This PR exposes a new `epsilon` function in the `Float` trait so that users can access the `EPSILON` constant on the float types. I figured as this was such a minimal change it was easier to get a PR in offering the change then write up an issue.
For me this is a valuable addition. When writing linear algebra or other optimization routines with generic floats we often want to check if some stopping criteria is reached, often something like: `(a - b).abs() < eps`. Having access to a standard _small value_ would make this a little easier.
Use serde 0.8
I updated `bigint`, `complex`, and `rational` to use `serde 0.8`, and also fixed deserialization and the `serde` feature as such in the `rational` crate (didn't add any tests, but it compiles now).
Similar to https://github.com/rust-num/num/pull/196 for `num/complex`, “`use serde;`” needed to be removed in `num/rational`.
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.