-
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
volume command #1747
volume command #1747
Conversation
a187afc
to
5291c46
Compare
5291c46
to
4439cb0
Compare
b09ef47
to
85dde7b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This command doesn't seem all that useful to me, but I'm guessing you must have some particular use case(s) in mind?
85dde7b
to
427c8b6
Compare
427c8b6
to
4dd4f99
Compare
Yes. I don't have a particular use case for player robots, but I envision some interesting gameplay mechanics involving "enclosure" when used by system robots/goal conditions. The integration test scenario is one example. In contrast with the A few scenario ideas:
|
Ah, OK, yes, those sound nice! |
visitableNeighbors = filter (not . (`HashSet.member` visited tracking)) candidateNeighbors | ||
|
||
-- It's cheaper to prepend the "visitableNeighbors" list because | ||
-- it should in general be a shorter list than the "pending" list. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment seems a little misleading --- the reason for prepending the visitableNeighbors
is because we're treating pending
as a stack rather than a queue, not because it is more efficient (though I agree it will be). Regardless of which list is shorter, prepending the visitableNeighbors
will take constant time per new neighbor, and hence visitableNeighbors
will take time linear in the number of vertices in the queue, but the same vertices might be in the queue for multiple iterations, so we can end up doing more than
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason for prepending the
visitableNeighbors
is because we're treatingpending
as a stack rather than a queue, not because it is more efficient (though I agree it will be)
Well, I originally went about this intending to implement BFS, until I got to this line and realized that appending to the pending
list would be expensive (and I couldn't be bothered to use Seq
instead of []
). So I decided to prepend instead, which turned it into DFS.
Measures the volume of an enclosed space.
A useful alternative to the
path
command for goal checking.Demo