Skip to content

[numeral] [plugins] Remove Coq's Bigint module in favor of ZArith.#11742

Merged
coqbot-app[bot] merged 5 commits intorocq-prover:masterfrom
ejgallego:zarith+core
Aug 28, 2020
Merged

[numeral] [plugins] Remove Coq's Bigint module in favor of ZArith.#11742
coqbot-app[bot] merged 5 commits intorocq-prover:masterfrom
ejgallego:zarith+core

Conversation

@ejgallego
Copy link
Copy Markdown
Contributor

@ejgallego ejgallego commented Mar 3, 2020

We replace Coq's use of Bigint, Big_int and num by the ZArith OCaml
library which is a more modern version.

We switch the core files and easy plugins only for now, the remaining micromega plugins will be done in their own commit.

We thus keep the num library linked for now until micromega is ported.

Co-authored-by: Vincent Laporte Vincent.Laporte@fondation-inria.fr

Kind: feature / infrastructure.

  • Added / updated test-suite
  • Corresponding documentation was added / updated
  • Entry added in the changelog

Overlays:

@ejgallego ejgallego added kind: redesign The same functionality is being re-implemented in a different way. kind: cleanup Code removal, deprecation, refactorings, etc. kind: infrastructure CI, build tools, development tools. labels Mar 3, 2020
@ejgallego ejgallego requested review from a team as code owners March 3, 2020 21:49
@ejgallego ejgallego requested a review from a team March 3, 2020 21:49
@ejgallego ejgallego requested review from a team as code owners March 3, 2020 21:49
@ejgallego ejgallego added this to the 8.12+beta1 milestone Mar 3, 2020
@ejgallego
Copy link
Copy Markdown
Contributor Author

This PR ports Coq to ZArith except for micromega; it is the first part of #8743 ;

The porting is actually quite ortogonal so we could indeed make #8743 self-contained for micromega, but IMO I think this is close enough to be ready that it is not worth it.

@ejgallego
Copy link
Copy Markdown
Contributor Author

ejgallego commented Mar 4, 2020

Two problems:

  • windows build needs to install gmp + zarith
  • nix also needs gmp + zarith ?
  • coq_makefile using -linkall makes linking fail in OCaml >= 4.08, workaround pushed.

Bench : https://ci.inria.fr/coq/job/benchmark-part-of-the-branch/875/

@ejgallego
Copy link
Copy Markdown
Contributor Author

@maximedenes can we install libgmp-dev on pendulum? [I'm afraid my network situation is bad as I'm on the road]

@ejgallego ejgallego force-pushed the zarith+core branch 2 times, most recently from 4a72f50 to dd6ee16 Compare March 4, 2020 05:14
@ejgallego ejgallego requested a review from a team as a code owner March 4, 2020 05:14
@maximedenes
Copy link
Copy Markdown
Member

@maximedenes can we install libgmp-dev on pendulum? [I'm afraid my network situation is bad as I'm on the road]

Done.

@maximedenes
Copy link
Copy Markdown
Member

I have a fear releated to this PR: since the porting of micromega failed, how do we know that this is correct? Aren't we just porting less well-tested parts (Big_int is notorious for having has some undetected long-standing critical bugs, for example, IIRC)? I would feel more comfortable if we port everything at once.

Also, what is the motivation for this change if num is still a dependency?

@ejgallego
Copy link
Copy Markdown
Contributor Author

I have a fear related to this PR: since the porting of micromega failed how do we know that this is correct?

I'm not sure I understand what you mean about correctness; what is the particular concern you have in mind?

I don't think porting of micromega "failed", it just needs more work as there is not a 1-1 mapping of the APIs in a few places.

Aren't we just porting less well-tested parts (Big_int is notorious for having has some undetected long-standing critical bugs, for example, IIRC)?

What does Big_int has to do here? It is not involved in this PR IIANM; what do you mean about less "well-tested" parts? Both omega and the numeral notations are pretty well tested, and I'd say zarith/GMP is way more tested than num/bigint.

I would feel more comfortable if we port everything at once.

These are totally orthogonal components so I don't see any reason porting more stuff should increase the confidence on the current code.

@maximedenes
Copy link
Copy Markdown
Member

@ejgallego my worry is not about the correctness of ZArith/GMP, of course, it is precisely about the correctness of the API mapping.

What does Big_int has to do here? It is not involved in this PR

I imagined you were replacing the uses of Big_int by ZArith because that's literally what the PR title says, but I must have misunderstood.

Under that assumption, my point was that uses of Big_int were not well tested. So the replacement by ZArith will also not be well tested.

@ejgallego
Copy link
Copy Markdown
Contributor Author

I imagined you were replacing the uses of Big_int by ZArith because that's literally what the PR title says, but I must have misunderstood.

This is replacing Bigint, which is Coq's own version, Big_int is the one in OCaml [confusing I know]

@ejgallego my worry is not about the correctness of ZArith/GMP, of course, it is precisely about the correctness of the API mapping.

Under that assumption, my point was that uses of Big_int were not well tested. So the replacement by ZArith will also not be well tested.

Well that's hard to know, tho the API mapping performed this PR seems safe enough to me; I don't think the paths this PR modifies are not so well tested tho, they include omega and numeral notations, these are certainly used in quite a few places in the CI.

@ejgallego
Copy link
Copy Markdown
Contributor Author

ejgallego commented Mar 4, 2020

Done.

Thanks, let's see the new bench here https://ci.inria.fr/coq/job/benchmark-part-of-the-branch/877

@ejgallego
Copy link
Copy Markdown
Contributor Author

By the way micromega mostly works, I just don't have the time to fix it now, but it should not be hard. The problem is almost for sure in the particular spot where exponentation of rationals was used, but indeed there the old num API was allowing clients to do what seems like very weird things; so indeed we will have to improve code likely.

Note also that micromega uses big_int vs the parts of Coq that don't use it.

@liyishuai
Copy link
Copy Markdown
Member

What's the status of this PR?

@maximedenes
Copy link
Copy Markdown
Member

Sorry, I didn't merge in time because of summer vacations. @ejgallego would you mind rebasing?

@maximedenes maximedenes added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Aug 20, 2020
ejgallego and others added 5 commits August 27, 2020 19:03
We replace Coq's use of `Big_int` and `num` by the ZArith OCaml
library which is a more modern version.

We switch the core files and easy plugins only for now, more complex
numerical plugins will be done in their own commit.

We thus keep the num library linked for now until all plugins are
ported.

Co-authored-by: Vincent Laporte <Vincent.Laporte@fondation-inria.fr>
We could still optimize the functions in that file a bit more if there
is need.
Suggested by Pierre Roux
@ejgallego
Copy link
Copy Markdown
Contributor Author

@ejgallego would you mind rebasing?

Done.

@github-actions github-actions Bot removed the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Aug 28, 2020
@maximedenes
Copy link
Copy Markdown
Member

@coqbot merge now

@coqbot-app coqbot-app Bot merged commit 165aca8 into rocq-prover:master Aug 28, 2020
@coqbot-app
Copy link
Copy Markdown
Contributor

coqbot-app Bot commented Aug 28, 2020

@maximedenes: Please take care of the following overlays:

  • 08743-ejgallego-zarith.sh

@maximedenes
Copy link
Copy Markdown
Member

@coqbot Yes @coqbot, I shall do so. I hope you're having a good day. Thanks for merging!

@RalfJung
Copy link
Copy Markdown
Contributor

Is it possible that this broke opam-based Coq builds? #12937

When dependencies change, would be good if the opam package was either fixed at the same time, or the opam maintainers were notified ahead of time.

Comment thread INSTALL.md
- The [num](https://github.com/ocaml/num) library; note that it is
included in the OCaml distribution for OCaml versions < 4.06.0

- The [ZArith library](https://github.com/ocaml/Zarith) >= 1.8
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The version given here is inconsistent with what it says in the opam file (1.9.1).

JasonGross added a commit to JasonGross/coq-packaging that referenced this pull request Aug 29, 2020
JasonGross added a commit to JasonGross/coq-packaging that referenced this pull request Aug 29, 2020
@bschommer
Copy link
Copy Markdown
Contributor

  • windows build needs to install gmp + zarith

For windows, this branch might be interesting since the libtommath builds fine under windows.

@MSoegtropIMC
Copy link
Copy Markdown
Contributor

  • windows build needs to install gmp + zarith

For windows, this branch might be interesting since the libtommath builds fine under windows.

Not sure what the issue is on Windows. The Coq platform does build gmp on Windows. The opam package works fine.

@bschommer
Copy link
Copy Markdown
Contributor

bschommer commented Nov 11, 2020

  • windows build needs to install gmp + zarith

For windows, this branch might be interesting since the libtommath builds fine under windows.

Not sure what the issue is on Windows. The Coq platform does build gmp on Windows. The opam package works fine.

If one wants to use the msvc, one does not get to far with the gmp, mpir (the gmp fork with different license and build script for visual studio) gave up on releasing new versions. Of course gmp should normally work if you use mingw or cygwin.

Edit: Also if one wants to vendor zarith packing libtommath additionally would avoid one system dependency.

@ejgallego
Copy link
Copy Markdown
Contributor Author

@bschommer vendoring zarith would be an option, I'd be happy to finish ocaml/Zarith#73 if the zartih devs give the OK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind: cleanup Code removal, deprecation, refactorings, etc. kind: infrastructure CI, build tools, development tools. kind: internal API, ML documentation...

Projects

None yet

Development

Successfully merging this pull request may close these issues.