Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

primality constraint #882

Merged
merged 8 commits into from
Sep 30, 2020
Merged

primality constraint #882

merged 8 commits into from
Sep 30, 2020

Conversation

robdockins
Copy link
Contributor

Dust off some experimental work on a type-level primality constraint, and push it forward.

This PR implements a primality constraint, which is implemented in the typechecker via a probable prime test. The type Z p is added to the Field class under the constraint prime p, and recip is defined via EGCD for concrete values. For symbolic values, the What4 backend posits the multiplicative inverse via a defining equation. The SBV backend needs to be enhanced with the same definition equation capability the What4 backend has to complete this work.

@robdockins
Copy link
Contributor Author

The primality constraint and prime field inverses are now fully implemented. Remaining tasks are to add some unit tests and documentation.

@brianhuffman
Copy link
Contributor

Do the changes to the Cryptol.Eval.SBV API in f3e5200 make sense on their own? This might be easier to review if that was split into a separate PR.

@robdockins
Copy link
Contributor Author

Do the changes to the Cryptol.Eval.SBV API in f3e5200 make sense on their own? This might be easier to review if that was split into a separate PR.

Yeah, that might make sense. I was planning to also unify some of the What4 and SBV code paths, and maybe all of that makes more sense as separate PR.

Copy link
Contributor

@brianhuffman brianhuffman left a comment

Choose a reason for hiding this comment

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

Looks good to me. At first I was a bit unsure about using a trie to cache primality checks; is the time savings worth the memory cost? But considering the typical use case, it probably is: Users will have a few fixed (probably large) prime constants in their source files, and you'll have to discharge primality constraints on the same numbers every time you use one of the overloaded primitives.

and the What4 symbolic simulator.

We use the EGCD algorithm to compute inverses for concrete values.
For symbolic values, we posit a multiplicitive inverse via a defining
equation.  To get this to work, we needed to fix a bug in the
equation definition code for What4; it was asserting definitions
with the wrong polarity for "prove" calls.
This involves adding the ability to assert definitional
relations, and porting the What4 method for modular inverse.
modular inverse computations instead of using the arithmoi and
semiring packages.
and finite field inverse computations.
@robdockins robdockins merged commit 1715535 into master Sep 30, 2020
robdockins added a commit to GaloisInc/saw-core that referenced this pull request Oct 8, 2020
Tracks the changes in Cryptol from GaloisInc/cryptol#882
which adds primality testing to the Cryptol type system, and implements
field operations for `Z p`.  Currently, we don't represent the primality
test in SAWCore, but we might revisit this aspect in the future.
brianhuffman pushed a commit to GaloisInc/saw-script that referenced this pull request Oct 10, 2020
brianhuffman pushed a commit to GaloisInc/saw-script that referenced this pull request Oct 12, 2020
@RyanGlScott RyanGlScott deleted the primes2 branch March 22, 2024 14:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants