I am trying to understand a particular Ruby implementation of the recursive-backtracking algorithm which generates mazes: https://weblog.jamisbuck.org/2010/12/27/maze-generation-recursive-backtracking
I have read up and (to some level at least) understood the steps in the algorithm. However, due to my inexperience in Ruby and particularly dealing with bitwise operations, the recursive method Jamis Buck has provided in this blog of his is really confusing me. Particularly, line 40 and 41:
grid[cy][cx] |= direction
grid[ny][nx] |= OPPOSITE[direction]
I understand that the OR operations done here are to make it so that it fulfills the requirement of the cell being "already traversed" as seen in the conditionals:
... && grid[ny][nx] == 0
However, that's as far as I understand it. Why couldn't these just be booleans instead? What is the point of performing an OR operation on the grid[ny][nx] with the opposite direction originally stored?
Sorry if this is something trivial I'm just not seeing. Still rather new to algorithms and Ruby in general.
Imagine a maze as a grid of rooms, where each room has its own independent walls.
Why couldn't these just be booleans instead?
The author points that
I generally implement the field as a grid of bitfields (where the bits in each cell describe which direction passages have been carved)
He implemented the state of each room in 4 bits, where 0 is a wall, and 1 is a "passageway".
If you implement it with 4 booleans, you will spend more code and memory.
What is the point of performing an OR operation on the grid[ny][nx] with the opposite direction originally stored?
To carve a passageway between two rooms with independent walls you need to remove two walls.
Example: when you want to make the North passageway, you have to remove North wall of the current room and South wall of the adjacent room.
What is the meaning behind performing an OR operation on the "current" cell and the neighbor to its right?
(grid[y][x] | grid[y][x+1]) & S != 0 literally means "if current room OR right one has South passageway". Lets translate this part to pseudo code:
IF (current room has no Bottom wall) print " " ELSE print "_"
IF (current room has no Right wall)
IF (either(current room OR Right one) has no Bottom wall) print " " ELSE print "_"
ELSE
print "|"
END
With space changed for ., the bottom of two horizontally adjacent rooms(with passageway) could look like ___ or ... or .._ or _..
And Line 59 controls the logic of the second character in this pattern.
You can fix the seed (line 14) and than change bitwise OR for bitwise AND in line 59 ( (grid[y][x] & grid[y][x+1]) & S != 0 ) to see the change in display.
Related
I am trying to understand some ancient code from a DEC PDP10 written in BCPL. A sample of the code is as follows:
test scanner()=S.DOTNAME then
$( word1:=checklook.up(scan.info,S.SFUNC,"unknown Special function [:s]")
D7 of temp:=P1 of word1
scanner()
$) or D7 of temp:=SF.ACTION
What do the "D7 of temp" and "P1 of word1" constructs do in this case?
The unstoppable Martin Richards is continuing to add features to the BCPL language(a), despite the fact that so few people are aware of it(b). Only seven or so questions are tagged bcpl on Stack Overflow but don't get me wrong: I liked this language and I have fond memories of using it back in the '80s.
Some of the things added since the last time I used it are the sub-field operators SLCT and OF. As per the manual on Martin's own site:
An expression of the form K OF E accesses a field of consecutive bits in memory. K must be a manifest constant equal to SLCT length:shift:offset and E must yield a pointer, p say.
The field is contained entirely in the word at position p + offset. It has a bit length of length and is shift bits from the right hand end of the word. A length of zero is interpreted as the longest length possible consistent with shift and the word length of the implementation.
Hence it's a more fine-grained way of accessing parts of memory than just the ! "dereference entire word" operator in that it allows you to get at specific bits within a word.
(a) Including, apparently, a version for the Raspberry PI, which may finally give me an excuse to break out all those spare PIs I have lying around, and educate the kids about the "good old days".
(b) It was used for at least one MC6809 embedded system I worked on, and formed a non-trivial part of AmigaDOS many moons ago.
I built conway's game of life and its working fine but my game after many generations is either ending with no lives or reaching a stable pattern which it can't escape.
For example I have followed these rules
Any live cell with fewer than two live neighbours dies, as if by underpopulation.
(live_cell = True and neighourhood < 2)
Any live cell with two or three live neighbours lives on to the next generation.
(live_cell = True and neighourhood == 2 or neighourhood == 3)
Any live cell with more than three live neighbours dies, as if by overpopulation.
(live_cell = True and neighourhood > 3)
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
(live_cell = False and neighourhood == 3)
This is my game of life matrix where 1 is life and 0 not
000000
001000
010100
001000
000000
000000
and this is its corresponding neighbourhood maps created by my programe
011100
122210
124210
122210
011100
000000
After reaching this pattern even after thousands of generation its still stuck in this pattern itself. I dont know how to escape this pattern ?
If the space is finite, then the number of possible configurations is finite and then the GoL will end either in a stable pattern or in a loop. If the space is very small (as it looks like) then you will observe only stupid behavior. You need at least to use a much bigger space (500x500), fill it with 1's at many places and look; that is the basic play with GoL. The next step is to build interesting configurations, and there exists a lot that have been discovered over time, for examples see GoL Pattern Library. Basic well-known patterns are gliders, glider-guns, oscillators... You will discover that GoL is in fact a very interesting way of programming: the initial configuration is a program code executed by the machine that you can see evolving on your screen. But that programming is not so easy, especially if you want to obtain a specific behavior!
I'm trying to code AI for a game somewhat similar to Tic-Tac-Toe. You can see its rules here.
The min-max algorithm and analysis function I'm using can be found here
The way I've tried so far:
I've built some patterns which will be good for the current player. (in Python)
e.g. my_pattern = " ".join(str(x) for x in [piece, None, piece, piece, None])
I'm matching such patterns with all the 6 possible orientations on the hexagonal gameboard for every piece (not for blank spaces). To be precise, matching my_pattern with 6 different arrays (each array represents one of 6 different orientations).
Now, What should this analysis function actually calculate?
The score of entire state of board?
The score of the last move made on board?
If someone can accurately describe the purpose of Analysis function, that would be great.
The analysis function represents the current state of board. It may/ may not include the last move, any of the previous moves or the order of moves to reach a board position. It should also consider whose turn it is to play.
What I mean is the same board can be good/bad for white/black depending on whose turn it is. (Called the situation of zugzwang in chess).
Also, the same board can be reached in a variety of move sequences, hence, it depends on the type of game whether you want to include that in the analysis or not. (High level chess engines surely include order of moves, though not for calculating current board, but for further analysis on a possibility of reaching that position). In this game however, I don't think there is any need of including last or any of the previous moves (order) for your analysis function.
EDIT:
An example of analysis function:
value = 10000*W(4) - 10000*W(3) + 200*W(2.1) + 200*W(1.2) + 100*W(2) + 100*W(1.1) + 2*W(1e) + 10*W(1m) + 30*W(1c) - (10000*B(4) - 10000*B(3) + 200*B(2.1) + 200*B(1.2) + 100*B(2) + 100*B(1.1) + 2*B(1e) + 10*B(1m) + 30*B(1c))
where:
W = white
B = black pieces
4 = made line of 4 pieces
3 = made line of 3 pieces
2 = made line of 2 pieces having possibility of getting extended to 4 from atleast one side
. = blank (ie, 1.2 = W.WW on the board)
1.1 = Piece|Blank|Piece and possibility of extending to 4 from atleast one side
e|m|c = edge|middle|center of board, and possibility of extending to 4 from either sides
The positive result of this analysis function would mean white is better, 0 indicates balanced board and negative value means black has advantageous position. You can change the weights owing to the result of tests you will execute. However, finding all possible combinations is exhaustive task, but the game is such :)
Tic-Tac-Toe seems to be a fairly solved problem space, most 100% solutions seem to search through a finite tree of possibilities to find a path to winning.
However, I came across something from a computer-simulation toy from the 60's, The MiniVac 601. http://en.wikipedia.org/wiki/Minivac_601
This 'comptuer' consisted of 6 relays that could be hooked up to solve various solutions. It had a game section, which had this description on a program for Tic-Tac-Toe, that claims to be unbeatable as long as the Minivac went first.
Since most solutions to this seem to require lots of memory or computational power, its surprising to see a solution using a computer of 6 relays. Obviously I haven't seen this algorithm before, not sure I can figure it out. Attempts to solve this on a pad and paper seem to indicate a fairly easy win against the computer.
http://www.ccapitalia.net/descarga/docs/1961-minivac601-book5&6.pdf
"with this program, MINI VAC can not lose. The human opponent may
tie the game, but he can never win. This is because of the decision
rules which are the basis of the program. The M IN IV A C is so
programmed that the machine will move 5 squares to the right of its
own last move if and only if the human opponent has blocked that last
move by moving 4 squares to the right of the machine's last move. If
the human player did not move 4 squares to the right of the machine's
last move, M IN IV A C will move into that square and indicate a win.
If the hu man player consistently follows the "move 4 to the right"
rule, every game will end in a tie. This program requires that M IN IV
A C make the first move; the machine's first move will always be to
the center of the game matrix. A program which would allow the human
opponent to move first would require more storage and processing
capacity than is available on M IN IV A C
601. Such a program would, of course, be much more complex than the program which permits the machine to move first"
EDIT: OK so the Question a little more explicitly: Is this a real solution to solving Tic-Tac-Toe? Does anyone recognize this algorithm, it seems very very simple to not be easily searchable.
I think it is all in the layout of the "board". If you look at the 601 units tic-tac-toe area, 9 is in the middle and 1 is top left numbered sequentially clockwise around 9.
The "computer" goes first in the 9 position. The user then goes next.
If the user hasn't gone in position 1 (top left) then that is the next position for the computer. The user then goes next. Then the computer tries to go in position 1+4 (5 - bottom right). If the position is not available it will go in 1+5 (6 - bottom middle). x + 4 is always opposite the previous move, and since the computer has the center position it will be a winning move.
Recently I wrote a Ruby program to determine solutions to a "Scramble Squares" tile puzzle:
I used TDD to implement most of it, leading to tests that looked like this:
it "has top, bottom, left, right" do
c = Cards.new
card = c.cards[0]
card.top.should == :CT
card.bottom.should == :WB
card.left.should == :MT
card.right.should == :BT
end
This worked well for the lower-level "helper" methods: identifying the "sides" of a tile, determining if a tile can be validly placed in the grid, etc.
But I ran into a problem when coding the actual algorithm to solve the puzzle. Since I didn't know valid possible solutions to the problem, I didn't know how to write a test first.
I ended up writing a pretty ugly, untested, algorithm to solve it:
def play_game
working_states = []
after_1 = step_1
i = 0
after_1.each do |state_1|
step_2(state_1).each do |state_2|
step_3(state_2).each do |state_3|
step_4(state_3).each do |state_4|
step_5(state_4).each do |state_5|
step_6(state_5).each do |state_6|
step_7(state_6).each do |state_7|
step_8(state_7).each do |state_8|
step_9(state_8).each do |state_9|
working_states << state_9[0]
end
end
end
end
end
end
end
end
end
So my question is: how do you use TDD to write a method when you don't already know the valid outputs?
If you're interested, the code's on GitHub:
Tests: https://github.com/mattdsteele/scramblesquares-solver/blob/master/golf-creator-spec.rb
Production code: https://github.com/mattdsteele/scramblesquares-solver/blob/master/game.rb
This isn't a direct answer, but this reminds me of the comparison between the Sudoku solvers written by Peter Norvig and Ron Jeffries. Ron Jeffries' approach used classic TDD, but he never really got a good solution. Norvig, on the other hand, was able to solve it very elegantly without TDD.
The fundamental question is: can an algorithm emerge using TDD?
From the puzzle website:
The object of the Scramble Squares®
puzzle game is to arrange the nine
colorfully illustrated square pieces
into a 12" x 12" square so that the
realistic graphics on the pieces'
edges match perfectly to form a
completed design in every direction.
So one of the first things I would look for is a test of whether two tiles, in a particular arrangement, match one another. This is with regard to your question of validity. Without that method working correctly, you can't evaluate whether the puzzle has been solved. That seems like a nice starting point, a nice bite-sized piece toward the full solution. It's not an algorithm yet, of course.
Once match() is working, where do we go from here? Well, an obvious solution is brute force: from the set of all possible arrangements of the tiles within the grid, reject those where any two adjacent tiles don't match. That's an algorithm, of sorts, and it's pretty certain to work (although in many puzzles the heat death of the universe occurs before a solution).
How about collecting the set of all pairs of tiles that match along a given edge (LTRB)? Could you get from there to a solution, quicker? Certainly you can test it (and test-drive it) easily enough.
The tests are unlikely to give you an algorithm, but they can help you to think about algorithms, and of course they can make validating your approach easier.
dunno if this "answers" the question either
analysis of the "puzzle"
9 tiles
each has 4 sides
each tile has half a pattern / picture
BRUTE FORCE APPROACH
to solve this problem
you need to generate 9! combinations ( 9 tiles X 8 tiles X 7 tiles... )
limited by the number of matching sides to the current tile(s) already in place
CONSIDERED APPROACH
Q How many sides are different?
IE how many matches are there?
therefore 9 X 4 = 36 sides / 2 ( since each side "must" match at least 1 other side )
otherwise its an uncompleteable puzzle
NOTE: at least 12 must match "correctly" for a 3 X 3 puzzle
label each matching side of a tile using a unique letter
then build a table holding each tile
you will need 4 entries into the table for each tile
4 sides ( corners ) hence 4 combinations
if you sort the table by side and INDEX into the table
side,tile_number
ABcd tile_1
BCda tile_1
CDab tile_1
DAbc tile_1
using the table should speed things up
since you should only need to match 1 or 2 sides at most
this limits the amount of NON PRODUCTIVE tile placing it has to do
depending on the design of the pattern / picture
there are 3 combinations ( orientations ) since each tile can be placed using 3 orientations
- the same ( multiple copies of the same tile )
- reflection
- rotation
God help us if they decide to make life very difficult
by putting similar patterns / pictures on the other side that also need to match
OR even making the tiles into cubes and matching 6 sides!!!
Using TDD,
you would write tests and then code to solve each small part of the problem,
as outlined above and write more tests and code to solve the whole problem
NO its not easy, you need to sit and write tests and code to practice
NOTE: this is a variation of the map colouring problem
http://en.wikipedia.org/wiki/Four_color_theorem