Factoring bigint and rational out of libextra.

[pnkfelix]

(Left libextra/num/complex in place; real goal is to enable quick
iteration on bigint improvements.)

[pnkfelix]

To see what sort of bigint improvements I am talking about, see e.g. pnkfelix/rust@d669822

[alexcrichton]

Would it be possible to remove feature(globs)?

[pnkfelix]

@alexcrichton I'm willing to do it, but can we make that a follow-on patch, and land this first?

[pnkfelix]

oh wait, this can't land as is; the current tutorial uses rational and I hadn't updated that yet.

Closing temporarily, will reopen after I get make check working.

[huonw]

Can extra::complex go out too? (Maybe these can all go into a libnum?)

[thestinger]

I think complex and rational should be provided in separate libraries, but the big integer implementation is just going to make Rust look bad...

http://www.reddit.com/r/rust/comments/1xcq1q/c_gcc_vs_rust_wtf/

If someone needs big integers, they're going to use the implementation that's provided by default and have a bad experience with the language.

[pnkfelix]

@thestinger ... It is precisely that reddit post that led me to try to pull this out.

From my point-of-view, making the bigint a separate crate should make it easier for an end-developer to swap-in a GMP based implementation.

More importantly, the separate crate makes it far far easier to quickly iterate through performance improvements, like the one I linked above on pidigits. (And I'm sure there's a lot of more low-hanging fruit here -- but its only low-hanging if we can iterate quickly.)

[thestinger]

If it's provided in the official repository and built by default, then it's not different. It's what people are going to use by default and makes the language look like rubbish. It may or may not make the builds faster, but it doesn't make it any less official or harder to use. If anything, it makes it more discoverable because there's a whole crate for it rather than it being tucked away in extra. I doubt it will have competitive performance for years, so why present it as the best Rust can do by having it part of the official Rust distribution?

It's easier to iterate on it in an independent repository no tied at all to Rust's build system, and not requiring a whole clone of the Rust repository to avoid unnecessary rebuilds when switching between branches. It's currently not a very a useful library...

[pnkfelix]

@thestinger I'm not trying to make the builds of the standard library faster. I'm trying to make it easier for everyone to collectively improve the bigint library.

As for the question of how easy we can/should make it to swap in the GMP library (the limit of this line-of-thinking being that GMP becomes the default, and one would have to opt-out of using it), that seems totally orthogonal to the change suggested by this ticket. Am I missing something?

(update: this comment was in response to an earlier draft of thestinger's previous comment that made no mention of separate repositories. Github based dialogues are such fun...)

[thestinger]

It's far easier to iterate on the big integer library in a separate repository without the need to go through the serialized bors queue and deal with unnecessary rebuilds whenever something like LLVM is upgraded.

It's even more prominent than it is now if it's included in the official repository in a more focused crate. If we don't want people to infer their opinion of Rust from this library, then it shouldn't be part of the official Rust distribution before the embarrassing performance issues are fixed. No one is going to lose out by this being out of the official repository because it's not yet a useful library.

[pnkfelix]

@thestinger okay, now I understand what you are suggesting. Thank you for stating that clearly.

[pnkfelix]

@huonw I considered moving all three to a single libnum crate, but I didn't have much reason to go one way or the other, and decided that a libbigint crate of minimal size would be best for initial performance hacking.

[pnkfelix]

okay this passes make check now.

The suggestion from thestinger to remove bigint entirely is certainly an option, but for now I'd like to see how far we might get without having to go that far.

[liigo]

+1 for libnum, don't want to see too many crates. And bigint::BigInt VS.
num::BigInt, the later looks well.
2014年2月10日 上午7:30于 "Felix S Klock II" notifications@github.com写道：

@huonw https://github.com/huonw I considered moving all three to a
single libnum crate, but I didn't have much reason to go one way or the
other, and decided that a libbigint crate of minimal size would be best
for initial performance hacking.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12141#issuecomment-34591257
.

[pnkfelix]

Okay I will close this and open a fresh PR that puts bigint and rational (and complex) into a single libnum crate.