Conversation
…n stir_main theorem
…nts of AHIV22 into these
🤖 Gemini PR SummaryThis diff introduces a major refactoring and cleanup of the codebase, focusing on better organization and removal of obsolete components. Here is a summary of the key changes:
Analysis of Changes
Last updated: 2025-12-18 01:53 UTC. See the main CI run for build status. |
🤖 Gemini PR SummaryHere is the high-level summary of the changes: Refactoring
Fixes
Features
Documentation
Analysis of Changes
✅ **Removed:** 4 `sorry`(s)
❌ **Added:** 3 `sorry`(s)
🎨 **Style Guide Adherence**Based on the provided style guide and code changes, here are the violations found: File: File: File: 📄 **Per-File Summaries**
Last updated: 2025-12-28 00:53 UTC. |
|
@chung-thai-nguyen since you had done some refactoring already in a previous: does the organisation done in this refactoring seem fine to you? I've tried to mostly stick with your outline but made some things a bit more generic where we overlapped (e.g. generic filenames instead of explicit references to papers now that several files have content from multiple papers, ...) |
@alexanderlhicks The generic file names (in ProximityGap folder) looks reasonable if we want a centralized place for readers to find the proximity gap theorems available for usage (but likely not the definitions since they are already in ProximityGap/Basic.lean), e.g. in OracleReduction protocols. My main concern was due to the bloat of general files. For Interleaved.lean, most (if not all) proximity gap definitions/theorems can be written from the interleaved code POV. Similarly for ReedSolomon.lean, a lot of papers state proximity gaps for RS codes. 1 theorem might be put in both Interleaved.lean & ReedSolomon.lean if we don't have clear distinction in terms of purpose of the files. I think we can have these generic files but only for theorem statements across papers, and the helper lemmas should be put somewhere else if we really decide to have monolithic files like that in the long term. If we don't split helper lemmas, the files would look pretty long & distracted (e.g. the DG25 file is 2k lines and it is only about proximity gaps for multilinear combination, but its main theorems are short). But idk how should we do it atm. What do you think? |
Yep, beyond what's been done on this PR now (which is really just moving stuff across, particularly the STIR/WHIR contents), I think a next step (in this PR or a follow up) will be to see where we can clean up and unify results (STIR and WHIR alone have/had overlap given parts of the WHIR paper are literally copy pasted from the STIR paper), but this first requires setting up the file structure so that we know what boxes we to put things in.
Yep, I agree about the bloat. One option is to have small files for key results and split auxilliary/helpful lemmas across other files according to what they cover. See for example the edits I made to the proof of Polishchuk Spielman here: https://github.com/alexanderlhicks/ArkLib/pull/1/files, which keeps the proof of the main result in PolishchukSpielman.lean and splits intermnediary results across three files based on what they cover (if what they cover is not easily categorized, they can just be split into Aux.lean or Aux1.lean, Aux2.lean if they are too long...). |
|
@alexanderlhicks Yes, we really need to figure out the right file structure. Here I give some suggestions for your consideration:
For other tools like OOD, folding, ... we can continue as you do and I think we can unify sth out of different formulations of them (FRI/STIR/WHIR/Binius, etc). |
Opening up this PR/branch to refactor and clean up some of the contents of our coding theory formalization.
Initial commits: