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

fix: fix broken tests in runtime_bignum_test.nr #39

Merged
merged 21 commits into from
Nov 7, 2024

Conversation

charlielye
Copy link
Contributor

Description

After making the comptime generated test names unique, now some fail.

  • 6 fail if tests are run normally.
  • 7 fail if tests are run with --force-brillig

Someone more knowledgable than I will need to fix the tests before we can merge this.

PR Checklist*

  • I have tested the changes locally.
  • I have formatted the changes with Prettier and/or cargo fmt on default settings.

@kashbrti
Copy link
Contributor

kashbrti commented Oct 28, 2024

fixed an issue with the test_add (partly). The overflow test failed for the wrong reason. assert_bit_size in noir only works as expected when the input is constant.
Had to change the test_add temporarily because there's a logic issue with derive_from_seed (the outputs of the constrained and unconstrained functions don't match for BLS parameters).

@kashbrti
Copy link
Contributor

kashbrti commented Oct 31, 2024

there's an issue with brillig. in line 42 of unconstrained_helpers the value of the array addend_u60 is different in the loop (starting in line 53) and outside it if we run with --force-brillig flag

* main:
  fix: remove unnecessary generic (#42)
  migration notes (#38)
* main:
  chore: run formatter on imports (#43)
.vscode/launch.json Outdated Show resolved Hide resolved
@TomAFrench TomAFrench force-pushed the cl/unique_test_names branch from 30af00f to 59363d0 Compare November 7, 2024 13:03
Comment on lines 241 to 250
// this is a hack, the assert_max_bit_size is not working when limbs[i] is not a constant
// limbs[i].assert_max_bit_size::<120>();
assert(limbs[i].lt(2.pow_32(120)), "call to assert_max_bit_size 2");
}
limbs[N - 1].assert_max_bit_size::<MOD_BITS - ((N - 1) * 120)>();
// this is a hack, the assert_max_bit_size is not working when limbs[i] is not a constant
// limbs[N - 1].assert_max_bit_size::<MOD_BITS - ((N - 1) * 120)>();
assert(
limbs[N - 1].lt(2.pow_32((MOD_BITS as Field) - ((N - 1) * 120) as Field)),
"call to assert_max_bit_size",
);
Copy link
Member

Choose a reason for hiding this comment

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

The tests are all passing with the commented out range checks. Is this still an issue?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the asserts that I've added are doing the range check if I'm not making a mistake.
The issue was that as limb[N-1] is not a constant, the range check was happening for the bit size of the native field rather than the actual input.

Copy link
Member

Choose a reason for hiding this comment

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

Yep, I agree that the added asserts are going a less efficient range check.

The issue was that as limb[N-1] is not a constant, the range check was happening for the bit size of the native field rather than the actual input.

Why would a non-constant field result in us not performing a check whether limb[N-1] fits within MOD_BITS - (N-1)*120 bits?

Copy link
Member

Choose a reason for hiding this comment

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

Did you verify the output in the ACIR? If we're producing incorrect output here we shouldn't just hide that by rewriting the Noir.

Copy link
Member

Choose a reason for hiding this comment

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

To be 100% clear, I'd like to restore the original calls to assert_max_bit_size so I'm keen to know why they were replaced and if it's due to a correctness issue in the compiler then we need to fix that.

@TomAFrench TomAFrench requested a review from kashbrti November 7, 2024 13:23
@TomAFrench TomAFrench changed the title fix: Make test names unique. Fixes for now broken tests (TODO). fix: fix broken tests in runtime_bignum_test.nr Nov 7, 2024
@TomAFrench TomAFrench merged commit 63e6c85 into main Nov 7, 2024
5 checks passed
@TomAFrench TomAFrench deleted the cl/unique_test_names branch November 7, 2024 16:04
@github-actions github-actions bot mentioned this pull request Nov 7, 2024
TomAFrench added a commit that referenced this pull request Nov 8, 2024
* main:
  feat: remove generic parameter from the `BigNum` trait (#44)
  fix: fix broken tests in `runtime_bignum_test.nr` (#39)
  feat: remove a bunch of unnecessary bytecode from unconstrained ops (#50)
  fix: Fix barrett reduction bug (#51)
  feat: optimize brillig execution of `split_X_bits` functions (#47)
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