Since the Num constraint only requires val-val ops, we ended up cloning
everything in Complex ops when they were forwarded to ref-ref. By using
val-val, we can reduce how often clones are needed.
Implement arithmetic with real for complex
Hello,
It might be handy to be able to perform basic arithmetic operations in expressions mixing complex numbers and numeric primitives; see #116. I would be grateful for any feedback, especially regarding the subsets of primitives for which certain operations are implemented.
Regards,
Ivan
- Use explicit asserts for should-panic tests, since overflow is not
checked in release mode.
- Add positive tests where gcd min_value() can be represented.
- In all cases, test min_value() in both positions.
Closes#127
Removing extra parentheses in a for loop fixes this warning:
src/bigint.rs:1636:18: 1636:31 warning: unnecessary parentheses around `for` head expression, #[warn(unused_parens)] on by default
Making bignum optional allows skipping the rustc-serialize and rand
dependencies too, and it makes a big difference in num's build time.
With default (all) features, clean build time including dependencies: 27
seconds.
With no default features, clean build time including dependencies (none):
5 seconds.
For example, the following will print (4294967295, 65535):
extern crate num;
use num::traits::Bounded;
fn main() {
let t : (u32, u16) = Bounded::max_value();
println!("{:?}", t);
}
If T is an unsigned integer type, these methods are guaranteed to
overflow unless the result is actually real, so we should disallow
them for the same reason that Neg was removed from these types.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Along the way, this commit also rationalizes the traits a bit more.
Moving to stable required vendoring a couple of minor things (notably,
radix formatting).
This commit brings in a load of unstable and/or deprecated traits from
the `std::num` module. These traits provide for some degree of generic
programming over numeric types. They are not stable in `std` mostly
because we want more time to iterate on their design. Moving them to the
`num` crate allows existing code to keep using this functionality as we
do so.
Closes#74