Skip to content

fix: fix broken tests in runtime_bignum_test.nr#39

Merged
TomAFrench merged 21 commits intomainfrom
cl/unique_test_names
Nov 7, 2024
Merged

fix: fix broken tests in runtime_bignum_test.nr#39
TomAFrench merged 21 commits intomainfrom
cl/unique_test_names

Conversation

@charlielye
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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)
@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
Copy Markdown
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
Copy Markdown
Member

Choose a reason for hiding this comment

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

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.

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
@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