feat: even stricter word ram - #92
Draft
Shreyas4991 wants to merge 19 commits into
Draft
Shreyas4991 wants to merge 19 commits into
Shreyas4991 wants to merge 19 commits into
Conversation
… comparison bools
… I have reasons to kick this out
…delM to avoid nasty errors for the quicksort PRs. Then I started adding a loop combinator to WordRAM. there's also specs for Problems and algorithms. Now a good algorithm needs to be uniform across all input sizes
Owner
Author
|
The experiment continues. Turns out we can make this viable. previously this comment saidThis experiment is over. In an attempt to remove any loopholes that might allow this so-called "cheating", I used GPT to rapidly go to an almost- fully deeply embedded word RAM assembly. Of course this means going further and further away from the lightweight-ness of this Free monad based framework. Clearly this is not a suitable way to proceed. Nevertheless I learnt quite a bit about the trade-offs between the lighter #90 and this PR, and in general between free monad DSLs and deep embeddings, even in this toy setting. |
…simplified the docstrings
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is a variant of #90 which introduced a stricter RAM model. There we moved all operations arguments and return values to opaque registers whose values can only be known with the model. We did leave comparison operations out of this, they could return boolean values. Ofc one could reconstruct the input bit by bit in n*w comparison queries and bit operations and then do pure operations in that PR.
Here we firstly plug this leak. We also require correct
Progs to be free of lean parameters like the size of the input, so you can't pre-generate aProgfor each input size (that's to say, no non-uniformProgs should be allowed).The latter creates a conundrum. We don't have any Booleans to condition or parameters to recurse on. Therefore, we have also added constructors for
if-then-elseandwhile. To make life easy, there is now some syntax. Here's a linear search example from this PR:At this point we have a deeply embedded DSL. So why stick to Prog? Reductions are convenient to have. we can still work with looser query models and reduce some of them to WordRAM to get WordRAM algorithms where we only count operations we want to count.