-
Notifications
You must be signed in to change notification settings - Fork 52
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
Code golf scoring #866
Comments
Or number of AST nodes. |
Personally, I enjoy trying to optimize character count, but tastes vary. |
That can be fun, but I think there's more challenge in crafting a parsimonious program structure than shrinking variable names. I recognize appeal of finding out in which circumstances whitespace or semicolons are optional as well. Perhaps we can track both AST node count and character count as metrics? |
Sure, why not? 😄 I agree, both are fun for different reasons. One is about finding elegant program structures, as you say, and one is about pushing a language to its limits. |
This sounds fun and should be easy to add to current best score. 👍 I think it needs an “automated mode” where you can not cancel your solution and start writing in REPL. 🤔 |
I don't think I understand - what's the motivation? |
@byorgey well if you could continue in REPL, then an empty solution would be always shortest and then just finish it in REPL. |
I thought the idea was to count all things typed at the REPL plus anything run. |
But that way its always more efficient to type in REPL and step through. For example the sheep solution would not have to wait for wool to drop, if the player waits for it. I.e. the “solution” would not have to be full, which is OK, but different from other code golf challenges. |
Also if you wanted to count REPL, you would have to do it at each command because of Counting once is much simpler and would not litter the codebase. |
Ah, I think I see your point now. It's also harder to share short solutions if they require typing multiple things at the REPL. I agree, to keep things simple and consistent we should probably just score a single |
Perhaps for now, one shall only be qualified for code golf scoring when using the |
Maybe we could allow either Then we could have states NoEntry, EntryWithLength and MoreEntries. If you finish the game with second state, it’s considered for shortest solution. |
I wonder if it might be interesting to have constraints on the "stored code size" of a robot for a challenge. Perhaps by default all built robots have an "infinite memory bank", but we could define a "finite memory bank" entity. Perhaps possessing many of these entities avails the robot to some multiple of AST nodes. |
towards #866 NOTE: #1116 should be merged first so that the schema change of save files is less disruptive. ## Examples Different criteria can have their own best score: ![image](https://user-images.githubusercontent.com/261693/219904496-fcd23ca0-b208-43e1-afc6-188acfe327cf.png) All criteria share the same single best score: ![image](https://user-images.githubusercontent.com/261693/219904553-abe3011c-41b0-469c-b34d-95d84b91697a.png) ## Behavior notes * As currently designed, the code size will only be scored if the the player has specified their code **before** the scenario begins. Furthermore, any input into the REPL will invalidate code size scoring for the current game. * Because of this, the only way to score code so far is with a command-line argument of `--run` or `--autoplay`. However, #1010 shall implement code size scoring when a scenario is launched from the UI. * In the "best scores" display, if multiple "best score" criteria were all from the same game, they will be consolidated. If all criteria are for the same game, the criteria labels will be omitted. * The code size metrics will not be displayed if a "best score" was not obtained via `--run`. ## Caveats ### `run` command Currently, the code entailed in a `run "somescript.sw"` command is not transitively included, so using `run` make the code size score meaningless. ## Testing ### Unit tests Run the subset of unit tests: scripts/run-tests.sh --test-arguments '--pattern "Tests.Precedence"' ### Manual integration tests First, reset the score: rm -f ~/.local/share/swarm/saves/Tutorials_grab.yaml Saving the following to `grab-soln.sw`: ``` move; move; grab; turn back; move; turn back; move; move; grab; turn back; move; turn back; move; move; grab; turn back; move; turn back; move; move; grab; turn back; move; turn back; move; move; grab; turn back; move; turn back; move; move; grab; ``` Run as follows: scripts/play.sh --scenario Tutorials/grab.yaml --run grab-soln.sw This should establish a record for code size. Then, play the Grab tutorial and immediately paste and run this in the REPL: move; move; grab; move; grab; move; grab; move; grab; move; grab; move; grab; This solution is faster in terms of time, but should not displace the code-length record, since no code length should be recorded from a REPL solution.
It would be fun to keep track of the "best" solution in terms of code size.
The code size might be determined by summing all of the REPL executions plus all transitive inclusions of code (
include
orrun
).To discourage short variable names, it may be best to use "symbol count" rather than "character count" as the metric.
The text was updated successfully, but these errors were encountered: