Split num into several crates

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 traits are probably the most used part and still the most lightweight, they should definitely be their own crate.

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.

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.

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

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

Create empty traits crate

Move traits into num-traits crate

Auto merge of #164 - rust-num:split-into-crates, r=cuviper

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.

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.

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

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

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

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.

Move functions remaining in num to num-traits

Auto merge of #192 - vks:split-func, r=cuviper

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

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

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.

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.

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.

Merge pull request rust-num#102 from serde-rs/clippy

Navigation Menu

Repository navigation

Split num into several crates #102

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Split num into several crates #102

Description

Activity

bluss commented on Jul 10, 2015

vks commented on Sep 22, 2015

cuviper commented on Oct 16, 2015

kamalmarhubi commented on Feb 11, 2016

vks commented on Feb 11, 2016

vks commented on Apr 29, 2016

bluss commented on Apr 29, 2016

vks commented on Apr 29, 2016

cuviper commented on Apr 29, 2016

vks commented on Apr 29, 2016

cuviper commented on Apr 29, 2016

vks commented on Jul 8, 2016

cuviper commented on Jul 8, 2016

vks commented on Jul 8, 2016

cuviper commented on Jul 8, 2016

vks commented on Jul 8, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions