Add file that documents the thought behind problem order #167
Conversation
This file contains 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
|
Seems like a good idea, so I'm supportive. 👍 you switched tournament/robot-simulator and sublist/allergies. I'll try to help out with the dominoes description |
| problem | topics | ||
| ----- | ----- | ||
| minesweeper | managing board state, Vec, heavy logic | ||
| dominoes | The logic here isn't bad, I just don't quite understand the problem |
There was a problem hiding this comment.
I'd say "graph theory, searching". Most solutions to this exercise either take the graph-theoretical approach (find a Euclidean cycle) or search solutions until finding one that works. I'm not sure how nuanced you want to be here - one could reasonably solve this problem only knowing one of these two topics, I'm not sure if there should be an "OR" in there somewhere.
The downside of this file is that we have to keep in in sync with config.json. I'm not sure of a way to leverage travis.yml to check that for us. Though maybe there is an approach. Even with that drawback, I think having this file is useful. The PR that kicked of our problem ordering process is already out of date. And having something in the repo (instead of a gist or a blog post) makes it easier to find.
IanWhitney
force-pushed
the
document_problem_order
branch
from
559f73e to
a2e7000
Compare
This was referenced Jan 5, 2017
petertseng
added a commit
that referenced
this pull request
Jan 8, 2017
History: Thanks to the hard work of #167 and #127, we have topics in problems.md that tell why we ordered problems a certain way. After #229 (motivated by #179), we copied the topics into config.json, since now all tracks can take advantage of the "topics" concept. To reduce duplication, we can remove the topics and specific problems. This commit uses something more abstract, that states our values without going into the exact implementation. This requires less maintenance, and is less likely to go out of date than specifically listing problems. Since it only has the ordering philosophy and not the actual topics, it's time to rename it to problem_ordering.md. Closes #236
petertseng
added a commit
that referenced
this pull request
Jun 20, 2017
This has been a long time coming. Ever since #167 (comment) lifetimes should not have been a topic for rectangles. The reasons were discussed there already: * The "Putting it All Together" problems do not emphasise Rust language features in general. * The specific feature "lifetimes" is not implied by this problem. A sampling of ten submitted solutions shows two solutions with lifetimes. I used the exercism/problem-specifications#834 command to inspect other tracks' topics to see if we can glean any insight here. C#/F#: parsing, transforming Lua: strings, performance, control-flow (if/else, loops), algorithms Based on these, my recommendation: A possible topic is string parsing, because we are reading in a string and trying to make sense of it. However this is not parsing in the usual sense that one would use a parser for, which usually deals with text. If we were to declare "string parsing" a topic of rectangles, we would probably use it for ocr-numbers too (but we do not; the topics for ocr-numbers are lines, slices, chunks). "algorithm" is chosen because significant work will likely go into devising an algorithm for determining the rectangles, since that is not immediately obvious from the problem description. Solutions will likely display a diverse set of approaches. One might surmise that the alphametics exercise could have this topic as well, but this commit deals with rectangles only.
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.
The downside of this file is that we have to keep in in sync with
config.json. I'm not sure of a way to leverage travis.yml to check that for
us. Though maybe there is an approach.
Even with that drawback, I think having this file is useful. The PR that
kicked of our problem ordering process is already out of date. And
having something in the repo (instead of a gist or a blog post) makes it
easier to find.