Split num into several crates

[vks]

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?

[bluss]

The traits are probably the most used part and still the most lightweight, they should definitely be their own crate.

[vks]

I think we should create a new crate for the traits and the fractions (and maybe for range*) and abandon num. For complex numbers there is stainless-steel/complex, for bigints there are fizyk20/rust-gmp and Aatch/ramp. All of those are superior to the corresponding functionality in num.

[cuviper]

I agree these would be better separate. Really the only reason they're bundled is that num was a logical organization when they were all under the standard library, and they were pulled out en masse. Maybe now that we have the rust-num organization, we can start splitting them into specialized repos, leaving num as an umbrella crate for compatibility.

In defense of bigint, I think it's nice to have a library that's stable, universal, and pure-rust. Whereas rust-gmp depends on gmp, and ramp uses nightly features and arch-specific asm. It's ok with me that those are better than bigint in other ways, perhaps especially performance.

[kamalmarhubi]

I'd like to see the traits in their own crate as well.

[vks]

To move this forward, we could extract the traits and publish a num_traits crate on crates.io.

[vks]

This seems to be mostly done! The following function could still be moved to a sub crate crate: checked_pow, pow, abs_sub, sub, one, zero. Currently using them pulls in all crates, even if they are mostly not required.

[bluss]

one, zero are basically redundant now; A: Zero allows calling A::zero() which it did not do sometime before Rust 1.0 when this was designed.

[vks]

Still, I they could be moved to num_traits. Removing them would be a breaking change.

[cuviper]

Sure, if you want to move them and re-export at the top, that should be fine.

[vks]

Where should pow and abs go? They are quite generic and work for floats and integers, and probably even matrices. A new sub crate?

[cuviper]

Well abs is just a shell around Signed::abs, so that's fine going into num-traits.

pow is more generic, but I think logically we should keep it near checked_pow. I think it would be fine to put these into num-traits too, since that's the base of all num crates. It's also related to PrimInt::pow, though they aren't linked implementations.

[vks]

Since new functions have been added to num-traits, the version should probably be bumped to 0.2.

[cuviper]

New functions are generally not a breaking change on their own. Can you demonstrate a way that this could break someone's code?

[vks]

I thought 0.1 -> 0.2 is for new functions, not for breaking changes. The problem is that to use the new functions in num_traits, you would have to specify 0.1.34 (whatever version when they were moved from num) in the Cargo.toml, which seems counterintuitive, because that's not how it is usually done. 0.2 suggests that new functions were added.

[cuviper]

Cargo's semver has special treatment for leading zeros. 1.x to 1.y would be a compatible upgrade, usually just with added functionality like you say, but 0.x to 0.y is not considered compatible.

[vks]

I see. I still think having to depend on 0.1.34 is confusing, but I guess it's ok if it adheres to Cargo's definition.