Rebase of pull request #193. Addresses issue #8.

Implementation of BigDecimal, which comprises a BigInt and a u64 scale factor, allowing for storage of 2^64 digits.

Further implementation is required to set the default maximum precision (so numbers like 1/3 are not represented by 2^64 digits). The current default is 100.

Add, Sub, Mul implemented by @iterion, I reimplemented Div, Eq, FromStr.

Current solution follow syntax proposed in rust-lang/rfcs#1681.

Tracking issue rust-lang/rust#35900

Close #227

Code broken after change:

• [ ] https://github.com/kdar/gameboy-rs
• [ ] https://github.com/lemonrock/mbedtls
• [ ] https://github.com/timorantalaiho/kelaa
• [ ] https://github.com/dylanede/cef-rs
• [ ] https://github.com/klutzy/aheui-llvm
• [ ] https://github.com/pcwalton/rust-media
• [ ] https://github.com/PistonDevelopers/hematite_server

I added add and subtract methods that take an operand by value, instead of by reference, so they can work in place instead of always allocating new BigInts for the result.

I'd like to hear if anyone knows a better way of doing this, though - with the various wrappers/forwardings doing this for all the operations is going to be a mess and add a ton of boilerplate. I haven't even tried to do a complete job of it yet.

I'm starting to think the sanest thing to do would be to only have in place implements of most of the operations - and have the wrappers clone() if necessary. That way, the only extra work we're doing is a memcpy(), which is a hell of a lot faster than a heap allocation.

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

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.

Currently num mixes functionality that IMHO should be separate:

• bigints
• generic traits (One, Zero, FromPrimitive, ToPrimitive, ...)
• fractions
• complex numbers
• range*

The biggest offender are bigints, which are implemented very inefficiently. Real-world programs would probably rather use GMP or ramp.

The best plan of action would probably be creating the smaller crates and deprecating num?

The memory layout is probably already identical to C's complex type or std::complex<T>, but it'd be nice to make it explicit. This would help with C interop, and things like real-only FFTs that need to cast real-only vectors into vectors of alternating real/imaginary.

Is there any interest for having conversion from f32/f64 to Ratio? I've implemented that in my code, based on a continued fractions algorithm: https://github.com/sdroege/gst-plugin-rs/blob/d72f1f716b630bc31973fc559c5f5d82255965a1/gst-plugin/src/utils.rs#L53

The same algorithm is used in GStreamer since a decade or so, for handling framerates stored as a floating point number and similar things, and it generally gives good results, but it's of course not the only way of doing that and depending on the input values another algorithm might find "nicer" results.

If there's interest, I could prepare a pull request for moving that code over (and generalize it a bit).

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.

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.

This commit implements from_bytes and to_bytes methods for BigInt and BigUint. These methods are very useful when working with BigInt types.

The current code works with big-endian slices/vectors, while the existing code (new() and from_slice()) uses little-endian slices/vectors. My opinion is that big-endian is preferable, but I can change this if necessary.

The num crates are very important to the entire rust ecosystem, and my experience from using them is that they are very mature. But they are all still at v0.x. Is there anything that prevents bumping them all to v1.0?

Based on the documentation:

/// Returns true if the number is positive and false if the number is zero or negative.
fn is_positive(&self) -> bool;

/// Returns true if the number is negative and false if the number is zero or positive.
fn is_negative(&self) -> bool;

However, for signed integer types, we have the following, which matches the documentation:

#[inline]
fn is_positive(&self) -> bool { *self > 0 }

#[inline]
fn is_negative(&self) -> bool { *self < 0 }

But then for floating point types we have:

/// Returns `true` if the number is positive, including `+0.0` and `INFINITY`
#[inline]
fn is_positive(&self) -> bool {
    FloatCore::is_sign_positive(*self)
}

/// Returns `true` if the number is negative, including `-0.0` and `NEG_INFINITY`
#[inline]
fn is_negative(&self) -> bool {
    FloatCore::is_sign_negative(*self)
}

And so with a simple test like this:

dbg!(Signed::is_positive(&0i32));
dbg!(Signed::is_positive(&0.0f32));

We get:

Signed::is_positive(&0i32) = false
Signed::is_positive(&0.0f32) = true

I'm not sure what the best approach here (i.e. should 0 count as positive or not for floating point).

But the behavior should be consistent between floats and ints, and match the documentation on the Signed trait. Otherwise it leads to really subtle and dangerous arithmetic errors.

The solang compiler uses this crate for integer literals, which can 256 bits in Solidity.

However formatting bigints with Display is not great.

contract c {
     int256 constant a = 1e1000;
}

gives the diagnostic:

error: literal 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 is too large to fit into type 'int256'

It would be nice if we had a .to_human_readable() function which would either use e notation or what solc does:

Error: Type int_const 1000...(993 digits omitted)...0000 is not implicitly convertible to expected type int256. Literal is too large to fit in int256.

This would work for large numbers which don't consist of lots of zeros too.

I'm interest in having a trait that return the number of bits of T, std only have associated constant, u8::BITS. Similar to num::Bounded.

Alternative, let n_bits = std::mem::size_of::<T>() * u8::BITS as usize;.

Currently binomial coefficient ${n \choose k}$ is implemented when n and k are both integers. However, the generalized binomial coefficient allows n to be any complex number. At least, it's common situation to use binomial coefficients when n is a real number.

I'm especially interested in the implementation of Distribution<num::Ratio> for Standard and the UniformSampler backend to use gen_range() on custom types that wrap num::Ratio