-
Notifications
You must be signed in to change notification settings - Fork 35
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
Repair U32Table's Permutation Arguments #16
Comments
I currently believe the issue to be due to the difference of updating the running products between the processor and the u32 coprocessor. In the Processor Table, the running product of any u32 instruction – say, However, the U32 Table has no knowledge about the instruction thas was executed by the processor. All 5 running products are being updated whenever the indicator It is not a viable solution to simply update all running sums in the Processor Table whenever It might be necessary to carry the current instruction over to the U32 Table. Relates to #8 somewhat less loosely now. |
Additionally, if the processor never executes any u32 instruction, the running product of any of the 5 Permutation Aguments will equal the respective (prover-chosen) initial in the Processor Table, whereas the U32 Table will have no rows. #10 fixes this. |
- the u32 table gets additional base column “current_instruction” `ci` - the single permutation argument is conditional to `ci` and `idc` - both involved tables have considerably fewer extension columns - resolves the first half of #16
Closing in anticipation of #10. |
Small caveat: if the processor never executes a u32 instruction, this argument will fail. This artifact disappears once all tables are padded to the same height.
Currently, none of the 5 running products of the Permutation Arguments between the U32 Table and the Processor Table match up. Repair them.
Loosely relates to #8.
(Originally issue number 37 in the internal issue tracker.)
The text was updated successfully, but these errors were encountered: