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

Documentation and minor robustness changes #14

Merged
merged 26 commits into from
Nov 11, 2024

Conversation

GottfriedHerold
Copy link
Collaborator

@GottfriedHerold GottfriedHerold commented Nov 4, 2024

This PR mostly adds documentation changes that I wrote while trying to understand the codebase.
It intentionally does not do functional changes.

The only actual code changes are additions of some assert! guards, adding some extra tests
and splitting some functions more cleanly into parallel / non-parallel versions.
The latter is done to simplify testing and enable differential tests (which the old version could not do, because only one version was compiled).

GottfriedHerold and others added 26 commits September 23, 2024 17:13
- Document behaviour of to_binary (specify the endianness and what happens if value > 2**n_bits).
- Add test for to_binary
- Document base_decomposition
…more precise what they do, because there is some ambiguity from the name alone.
…r accordingly), because it lacks a bounds-check for the given indices.
…Mut::ptr_at_mut. These bounds-check are repeated in the respective sole caller (which is not unsafe). Alternatively, we could remove declare ptr_at and ptr_at_mut as *not* unsafe.
ntt/utils.rs: added tests and improved documentation
ntt/utils.rs: Changed lcm(a,b) slightly to avoid a potential overflow of an intermediate result. Now it overflows iff the result overflows.
…n split into two versions (parallel | non-parallel) rather than an inline #[cfg], because that makes it hard to write unit tests.
…worked tests and added test for transpose_square_swarp
…ariables in BinaryHypercube. The current implementation asserts num_variables < 32 or 64 (platform-dependent).
@GottfriedHerold GottfriedHerold changed the title This PR mostly add documentation to the codebase that I was writing while trying to understand the code. Documentation and minor robustness changes Nov 4, 2024
@@ -1,13 +1,24 @@
#[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]

// TODO (Gotti): Should pos rather be a u64? usize is platform-dependent, giving a platform-dependent limit on the number of variables.
Copy link
Owner

Choose a reason for hiding this comment

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

Yes, I would guess that even u32 would be enough, but let's do u64 to be safe.

@@ -4,12 +4,24 @@ use ark_ff::Field;

use super::{hypercube::BinaryHypercubePoint, MultilinearPoint};

/// There is an alternative (possibly more efficient) implementation that iterates over the x in Gray code ordering.
Copy link
Owner

Choose a reason for hiding this comment

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

Yes, we had it implemented here: https://github.com/compsec-epfl/space-efficient-sumcheck/blob/main/src/provers/hypercube.rs
Not 100% sure if we are using this iterator anywhere at the moment.

@@ -16,22 +21,37 @@ pub fn to_binary(value: usize, n_bits: usize) -> Vec<bool> {
result
}

// TODO(Gotti): n_bits is a misnomer if base > 2. Should be n_limbs or sth.
// Also, should the behaviour for value >= base^n_bits be specified as part of the API or asserted not to happen?
Copy link
Owner

Choose a reason for hiding this comment

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

Let's assert it out of existence ;)


result
}

// Gotti: Consider renaming this function. The name sounds like it's a PRG.
// TODO (Gotti): Check that ordering is actually correct at point of use (everything else is big-endian).
Copy link
Owner

Choose a reason for hiding this comment

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

This randomness can actually be in whatever order we want, as long as it is self-consistent

Copy link
Owner

@WizardOfMenlo WizardOfMenlo left a comment

Choose a reason for hiding this comment

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

LGTM!

@WizardOfMenlo WizardOfMenlo merged commit 3c764b4 into WizardOfMenlo:main Nov 11, 2024
1 check passed
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