roadmap for next versions of BigInts (>=0.6.0)

[dlesnoff]

It has been almost a year since last release of BigInts. I would like to prioritize issues, and know which features are expected for the next release (next tag) of BigInt. There are no labels put on issues right now.

I noticed there is almost no information for new developer to know what the developers are currently working on. I fear we might be multiple people working on the same thing in the future.

Here I will manage a list, that presents some features in other multiprecision libraries that is not yet implemented here, and I will try to link the current issues to that list. Please add a comment if the list is not up-to-date or you want another feature to implement (in addition to a new issue concerning that feature). Could you tell me which one you expect to see in BigInts 0.6.0, in BigInts 0.7.0, or in BigInts 1.0.0 ?

• [ ] Karatsuba multiplication (for 0.6.0 ?)
• [ ] Other fast multiplication : Tom-Cook, Schönhage-Strassen, FFT (for 0.7.0 ?)
• [ ] more string formatting #52 (for 0.6.0, this should not take too much time)
• [ ] another type representation of BigInt #43 (This might break a lot of things, and should quickly be considered in my opinion).
• [ ] type casts : signed and unsigned int #72, float and double (for 0.6.0)
• [ ] examples : for a new release, I think examples at least should work #73
• [ ] bitwise not
• [ ] arithmetic functions : is(Probab)Prime(n) (No issue yet), legendre & jacobi symbol, binomial coefficient, fibonnaci, factorial (These might be the object of another library of course).
• [ ] gcd (PR #75), lcm (for 0.6.0)
• [ ] sqrt, isSqrt (for 0.7.0)
• [ ] a benchmark folder, might be considered, in addition to the examples.
• [ ] Montgomery multiplication : squaring is faster than multiplying
• [ ] fast Division
• [ ] integrate examples in the CI

[konsumlamm]

I noticed there is almost no information for new developer to know what the developers are currently working on. I fear we might be multiple people working on the same thing in the future.

I'm pretty sure that's just because noone is working on anything (besides the open PRs).

Another thing we should agree on and document is the versioning policy (there is no officially recommended one afaik). One possibility is using semver. We should keep in mind that some of the changes so far are technically breaking (adding new exceptions that can be raised), but that would be ok for 0.6 with semver. Also note that bigints.nimble currently says the version is 1.0.0.

cc @narimiran

[pietroppeter]

I fear we might be multiple people working on the same thing in the future.

I like the optimism ;)

[dlesnoff]

Also note that bigints.nimble currently says the version is 1.0.0. Can we downgrade the nimble version to the last tagged one ? Another thing we should agree on and document is the versioning policy (there is no officially recommended one afaik). One possibility is using semver.

I thought semantic versioning was the official one for nimble packages. Do you know some other versioning policies ? I am for semver. We should be careful with the API though. To detect changes, we want to integrate the examples into the CI. Who decide when a new release is made ? Some breaking change in the API might be reverted back by a future commit. I am thus against : a breaking change implies a new release.