-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add shootout meteor contest benchmark. #10478
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
Conversation
This implementation of the meteor contest implements: - insertion check with bit trick; - pregenetation of every feasible placement of the pieces on the board; - filtering of placement that implies unfeasible board - central symetry breaking
}).to_owned_vec(); | ||
|
||
// translating to (0, 0) as minimum coordinates. | ||
for p in res.mut_iter() { |
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.
Would it be possible to use a different variable name than p
? (there are 5 separate things called p
in this function.)
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.
I can change the parameter of the function to piece
, and the others to cur_piece
. Is it better? Is it sufficient?
In fact, every p
is the piece in the pipe of the transformation. In Haskell, it would be done using composition of function without explicit argument.
… iterate Writing iterate(x, f) is more logical as rust iterator pipeline is left to right.
This implementation of the meteor contest implements: - insertion check with bit trick; - pregenetation of every feasible placement of the pieces on the board; - filtering of placement that implies unfeasible board - central symetry breaking related to #2776
`SpanlessEq` improvements fixes rust-lang#9775 Also includes a simplification to `consts::constant`'s interface since I was already touching the code. At the start of `eq_expr` the check: ```rust if !self.inner.allow_side_effects && left.span.ctxt() != right.span.ctxt() { return false; } ``` was removed. This was added in 49e2501 to handle `cfg` macros. This is better handled by the newly added `check_ctxt`. changelog: [various lints]: Don't consider different `cfg!` expansions to be the same unless they are for the same config. changelog: [various lints]: Don't consider the expansion of two different macros to be equal, even when they expand to the same token sequence. changelog: [various lints]: Don't consider two blocks to be equal if they contain disabled code or empty macro expansions, unless those section contain the exact same token sequence.
This implementation of the meteor contest implements:
board;
related to #2776