-
Notifications
You must be signed in to change notification settings - Fork 305
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
refactor: protogalaxy relations #1897
Conversation
std::array<FF, d> variables{}; | ||
for (auto& u_i : variables) { | ||
u_i = FF::random_element(); | ||
pow_univariate.partially_evaluate(u_i); | ||
} | ||
|
||
FF expected_eval = proof_system::honk::power_polynomial::evaluate<FF>(zeta, variables); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Legible, by-hand test is better AND it decouples this test from a very large module.
@@ -0,0 +1,57 @@ | |||
#pragma once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other git mv
s display as such, but this one doesn't (?).
public: | ||
using FF = FF_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exposing this alias clarifies what's happening in relation_types.hpp
@@ -20,8 +18,8 @@ template <typename FF> class AuxiliaryRelationBase { | |||
static constexpr size_t LEN_4 = 6; // RAM consistency sub-relation 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather expose an array but there's no easy way to unpack an array to a parameter pack.
const auto& extended_edges, | ||
const RelationParameters<FF>& relation_parameters, | ||
const FF& scaling_factor) | ||
inline static void accumulate(typename AccumulatorTypes::Accumulators& accumulators, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name didn't make sense anymore once the function was reused for more than just univariates.
@@ -0,0 +1,118 @@ | |||
#pragma once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have mostly tried to make this more legible by giving things more accurate names. I think a deeper rework would be nice but there's not time now.
* For this purpose, we simply feed (the same) random inputs into each of the two implementations and confirm that | ||
* the outputs match. This does not confirm the correctness of the identity arithmetic (the identities will not be | ||
* satisfied in general by random inputs) only that the two implementations are equivalent. | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've significantly reworked these relation consistency tests to simplify them, as they now don't need to test separate code paths (each relation implementation now contains a single function called accumulate
).
There was a problem hiding this 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, as discussed it would be nice to add an issue about the remaining refactorings that need to be done
BarycentricData<FF, 2, 6> barycentric_2_to_6; | ||
for (auto _ : state) | ||
{ | ||
DoNotOptimize(barycentric_2_to_6.extend(univariate)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the purpose of this DoNotOptimize
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From https://github.com/google/benchmark/blob/main/docs/user_guide.md#preventing-optimization
DoNotOptimize() forces the result of to be stored in either memory or a register.
Since the result of extend
is not used, the compiler would most likely optimize away the function call, meaning at the benchmark would measure the cost of doing nothing.
|
||
template <class Fr, size_t view_length> class UnivariateView; | ||
|
||
// IMPROVEMENT(Cody) this is not used anywhere? Move to memeber function of U/snivariate? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// IMPROVEMENT(Cody) this is not used anywhere? Move to memeber function of U/snivariate? | |
// IMPROVEMENT(Cody) this is not used anywhere? Move to memeber function of Univariate? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also I think this is a stale comment from get_random
which has been moved from the test file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, fixed.
@@ -91,13 +85,13 @@ template <typename Flavor> class SumcheckProverRound { | |||
* | |||
* @tparam T : In practice, this is a Univariate<FF, MAX_NUM_RELATIONS>. | |||
*/ | |||
Univariate<FF, MAX_RANDOM_RELATION_LENGTH> batch_over_relations(FF challenge, | |||
const PowUnivariate<FF>& pow_univariate) | |||
barretenberg::Univariate<FF, MAX_RANDOM_RELATION_LENGTH> batch_over_relations( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what the best practices are here, but isn't it a bit too verbose to have barretenberg::*
everywhere?
I noticed that in the test file you included the various data structures with using declarations at the beginning of the file and maybe it's worth doing here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, but this is in a header so we shouldn't use using
outside of a function or class scope :/
* @param accumulator the term being calculated by a sequence of calls to this function | ||
* @param new_term the term to be accumulated | ||
* @param parameters inputs not varying between successive executions of this function | ||
* @param scaling_factor term to scale the new accumulator contribution by before incorporating it | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @param accumulator the term being calculated by a sequence of calls to this function | |
* @param new_term the term to be accumulated | |
* @param parameters inputs not varying between successive executions of this function | |
* @param scaling_factor term to scale the new accumulator contribution by before incorporating it | |
*/ | |
* @param accumulator the term being calculated by a sequence of calls to this function | |
* @param new_term the term added to the accumulator in this iteration of the function | |
* @param parameters inputs not varying between successive executions of this function | |
* @param scaling_factor scales the new_term before incorporating it into the accumulator | |
*/ |
#include <span> | ||
|
||
namespace proof_system::honk::sumcheck { | ||
namespace barretenberg { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there should be a comment somewhere that explains the difference between Univariate and UnivariateView
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added comments
}; | ||
|
||
public: | ||
using UnivariateAccumulatorsAndViews = typename RelationImpl::template GetAccumulatorTypes<UnivariateAccumulatorsAndViewsTemplate>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to have some comments in places like line 68-69 which take a while to understand unless very experienced with templates. Would be useful for future refactoring as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made an issue AztecProtocol/barretenberg#720 and referenced it in the head block comment, added a comment above Line 68.
return result; | ||
} | ||
|
||
static InputElements get_special() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a comment explaining why this is special?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
return result; | ||
} | ||
|
||
static InputElements get_special() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a comment here as well would be useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this 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, as discussed it would be nice to add an issue about the remaining refactorings that need to be done
Good idea, here it is: AztecProtocol/barretenberg#720 |
🤖 I have created a new Aztec Packages release --- ## [0.1.0-alpha63](v0.1.0-alpha62...v0.1.0-alpha63) (2023-09-08) ### Features * `GrumpkinScalar` type ([#1919](#1919)) ([3a9238a](3a9238a)) ### Bug Fixes * add retry to tag and docker actions ([#2099](#2099)) ([9f741f4](9f741f4)) * **breaking change:** change embedded curve scalar mul to use two limbs to properly encode the scalar field ([#2105](#2105)) ([070cc4c](070cc4c)) * broken bootstrap.sh after renaming `aztec-cli` dir as `cli` ([#2097](#2097)) ([2386781](2386781)) * browser test in canary flow ([#2102](#2102)) ([d52af6c](d52af6c)), closes [#2086](#2086) * check a note is read before nullifying it. ([#2076](#2076)) ([aabfb13](aabfb13)), closes [#1899](#1899) * circuits issues when building with gcc ([#2107](#2107)) ([4f5c4fe](4f5c4fe)) * COMMIT_TAG arg value in canary Dockerfile ([#2118](#2118)) ([a3d6459](a3d6459)) * dont assume safety of nvm ([#2079](#2079)) ([a4167e7](a4167e7)) * end-to-end aztec cli dependency issue ([#2092](#2092)) ([16ee3e5](16ee3e5)) * minor annoyances ([#2115](#2115)) ([a147582](a147582)) * padded printing for e2e-cli ([#2106](#2106)) ([5988014](5988014)) * remaining refs to clang15 ([#2077](#2077)) ([2c16547](2c16547)) * run e2e tests without spot ([#2081](#2081)) ([f0aa3ca](f0aa3ca)) * updated CLI readme ([#2098](#2098)) ([2226091](2226091)), closes [#1784](#1784) ### Miscellaneous * **circuits:** - remove dead code from cbind of private kernel circuit ([#2088](#2088)) ([43dc9d7](43dc9d7)) * **circuits:** remove dead code in cbind.cpp for public kernel ([#2094](#2094)) ([861f960](861f960)) * Conservatively raise the minimum supported clang version in CMakeList ([#2023](#2023)) ([f49c416](f49c416)) * **constants:** bump number of private reads and writes ([#2062](#2062)) ([ab6c6b1](ab6c6b1)) * **contracts:** Use autogenerated Noir interfaces where possible ([#2073](#2073)) ([bd6368b](bd6368b)), closes [#1604](#1604) * merge bb release-please ([#2080](#2080)) ([e89b043](e89b043)) * move storage into main.nr. ([#2068](#2068)) ([2c2d72b](2c2d72b)) * protogalaxy relations ([#1897](#1897)) ([35407e2](35407e2)) ### Documentation * **limitations:** limitations on ordering and logs of chopped notes ([#2085](#2085)) ([315ad3d](315ad3d)), closes [#1652](#1652) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Will resolve AztecProtocol/barretenberg#682 and AztecProtocol/barretenberg#685
extend
functions inBarycentricData
.Cf also my comments below.
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.