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

min const generics #186

Closed
wants to merge 13 commits into from

Conversation

jon-chuang
Copy link
Contributor

Replacement for #182
Mostly done, what's left is to review/decide on API issues/integrate with rest of codebase (like curves)


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (main)
  • Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
  • Wrote unit tests
  • Updated relevant documentation in the code
  • Added a relevant changelog entry to the Pending section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer

}
};
}

macro_rules! impl_field_square_in_place {
// macro_rules! impl_deserialize_flags {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
// macro_rules! impl_deserialize_flags {

}
r[$limbs + i] = carry;
carry = 0;
// macro_rules! impl_deserialize_flags {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
// macro_rules! impl_deserialize_flags {

@Pratyush
Copy link
Member

The macro infrastructure is kinda difficult to follow; is there a way to simplify it? Also, I think merging the additive_ops and multiplicative_ops macro complicates the macro impl for only a small benefit. Could we revert that change?


#[inline]
fn two_adic_root_of_unity() -> Self {
Fp::<P, N>(P::TWO_ADIC_ROOT_OF_UNITY, PhantomData)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Fp::<P, N>(P::TWO_ADIC_ROOT_OF_UNITY, PhantomData)
Self::new(P::TWO_ADIC_ROOT_OF_UNITY)


#[inline]
fn large_subgroup_root_of_unity() -> Option<Self> {
Some(Fp::<P, N>(P::LARGE_SUBGROUP_ROOT_OF_UNITY?, PhantomData))
Copy link
Member

@Pratyush Pratyush Jan 27, 2021

Choose a reason for hiding this comment

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

Suggested change
Some(Fp::<P, N>(P::LARGE_SUBGROUP_ROOT_OF_UNITY?, PhantomData))
P::LARGE_SUBGROUP_ROOT_OF_UNITY.map(Self::new)


#[inline]
fn multiplicative_generator() -> Self {
Fp::<P, N>(P::GENERATOR, PhantomData)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Fp::<P, N>(P::GENERATOR, PhantomData)
Self::new(P::GENERATOR)

if !self.is_zero() {
let mut tmp = P::MODULUS.clone();
tmp.sub_noborrow(&self.0);
Fp::<P, N>(tmp, PhantomData)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Fp::<P, N>(tmp, PhantomData)
Self::new(tmp)

@jon-chuang
Copy link
Contributor Author

jon-chuang commented Jan 28, 2021

The macro infrastructure is kinda difficult to follow; is there a way to simplify it? Also, I think merging the additive_ops and multiplicative_ops macro complicates the macro impl for only a small benefit. Could we revert that change?

I've added some comments.

The main reason why this is annoying is that there is a lot of duplicate definitions. I think the real issue is that the macro impl is complicated. In hindsight it is true that the complication of making generic over concrete cases is unnecessary, so now I instantiate separately for concrete cases.

@jon-chuang
Copy link
Contributor Author

To be quite honest, the limitations of const means that const generics at present buys little imo, under the hood, one is more or less instantiating concretely over limb types within ff anyway. So it's unclear what one should have expected or might hope is yet to be improved.

@Pratyush
Copy link
Member

To be quite honest, the limitations of const means that const generics at present buys little imo, under the hood, one is more or less instantiating concretely over limb types within ff anyway. So it's unclear what one should have expected or might hope is yet to be improved.

I think the issue pops up because we can't have const-generic-based where clauses. Maybe for the time being this PR can move over just the BigInt stuff, and we can revisit Fp later?

@jon-chuang
Copy link
Contributor Author

jon-chuang commented Feb 4, 2021

I would say that I prefer the previous method of just implementing concretely via macros. Using const generics while requiring literals for unrolls means some unpleasant workarounds that make it harder to modify the code.

@huitseeker
Copy link
Contributor

I would consider adding a check for the minimal rustc version supporting `min_const_generics.

In fact, I have this in a commit you can grab here:
huitseeker@c69b1ed

Here's a sample output on an older compiler:
https://gist.github.com/cd63c76a4e53c2f4bbf19f9ca29f4eba

@huitseeker huitseeker mentioned this pull request Mar 28, 2021
6 tasks
@mmagician mmagician mentioned this pull request Dec 30, 2021
6 tasks
@Pratyush
Copy link
Member

Pratyush commented Feb 9, 2022

Superseded by #372 and #379

@Pratyush Pratyush closed this Feb 9, 2022
CPerezz added a commit to CPerezz/algebra that referenced this pull request Dec 20, 2023
vlopes11 pushed a commit that referenced this pull request Dec 20, 2023
* feat: Add support for constraint usage within ark_bn254

This modifies the `Cargo.toml` with the following changes:
- Add `ark-r1cs-std` as an optional dependency.
- Add `ark-curve-constraint-tests` an a dev-dependency.
- Add `r1cs` feature which activates `ark-r1cs-std` depencendy.

(cherry picked from commit 48687352268d94a9dae74b50465273af15b0d132)

* feat: Add `constraints` module for Bn245

Resolves: #186

* fix: Fix cherry-picking issues

* chore: Conditionally activate `r1cs/std`.

activate std for ark-r1cs-std only if r1cs is enabled as suggested by
@vlopes11.
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.

3 participants