How is the legal moves function supposed to be used on python-chess?
By running this code and entering e2e4. It turns out that the move is invalid.
import asyncio
import chess
import chess.engine
engine = chess.engine.SimpleEngine.popen_uci("stockfish.exe")
board = chess.Board()
while not board.is_game_over():
legal_count = board.legal_moves.count()
move_list = list(board.legal_moves) # Find legal moves
print (move_list)
print(board)
mover = input("Indica tu movimiento: ")
if mover not in move_list:
print ("vuelve a introducir una movida válida")
mover = input("otra movida: ")
board.push_xboard(mover)
result = engine.play(board, chess.engine.Limit(time=0.1))
board.push(result.move)
print(board)
engine.quit()
When I go through the list I find that ... have this kind of value:
[Move.from_uci('g1h3'), Move.from_uci('g1f3')
So, is not from legal_moves where i get the legal moves from the user??
or is supposed that i have to enter the values that way?
I do not understand.
What I want is for the user to enter a value through the console "e2e4" and verify if the movement is possible. (by the way, i need that kind of coordenate "e2e4", not "e4" or "Nf3").
Thanks.
Convert the user input into the python-chess move format.
mover = input("Indica tu movimiento: ")
mover = chess.Move.from_uci(mover) # add this line
Then use:
board.push(mover)
instead of:
board.push_xboard(mover) # incorrect
as the stockfish engine is not an xboard engine, it is a uci engine.
Output:
python so_chess.py
[Move.from_uci('g1h3'), Move.from_uci('g1f3'), Move.from_uci('b1c3'), Move.from_uci('b1a3'), Move.from_uci('h2h3'), Move.from_uci('g2g3'), Move.from_uci('f2f3'), Move.from_uci('e2e3'), Move.from_uci('d2d3'), Move.from_uci('c2c3'), Move.from_uci('b2b3'), Move.from_uci('a2a3'), Move.from_uci('h2h4'), Move.from_uci('g2g4'), Move.from_uci('f2f4'), Move.from_uci('e2e4'), Move.from_uci('d2d4'), Move.from_uci('c2c4'), Move.from_uci('b2b4'), Move.from_uci('a2a4')]
r n b q k b n r
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
R N B Q K B N R
Indica tu movimiento: e2e4
r n b q k b n r
p p . p p p p p
. . . . . . . .
. . p . . . . .
. . . . P . . .
. . . . . . . .
P P P P . P P P
R N B Q K B N R
[Move.from_uci('g1h3'), Move.from_uci('g1f3'), Move.from_uci('g1e2'), Move.from_uci('f1a6'), Move.from_uci('f1b5'), Move.from_uci('f1c4'), Move.from_uci('f1d3'), Move.from_uci('f1e2'), Move.from_uci('e1e2'), Move.from_uci('d1h5'), Move.from_uci('d1g4'), Move.from_uci('d1f3'), Move.from_uci('d1e2'), Move.from_uci('b1c3'), Move.from_uci('b1a3'), Move.from_uci('e4e5'), Move.from_uci('h2h3'), Move.from_uci('g2g3'), Move.from_uci('f2f3'), Move.from_uci('d2d3'), Move.from_uci('c2c3'), Move.from_uci('b2b3'), Move.from_uci('a2a3'), Move.from_uci('h2h4'), Move.from_uci('g2g4'), Move.from_uci('f2f4'), Move.from_uci('d2d4'), Move.from_uci('c2c4'), Move.from_uci('b2b4'), Move.from_uci('a2a4')]
r n b q k b n r
p p . p p p p p
. . . . . . . .
. . p . . . . .
. . . . P . . .
. . . . . . . .
P P P P . P P P
R N B Q K B N R
Indica tu movimiento: g1f3
r n b q k b n r
p p . . p p p p
. . . p . . . .
. . p . . . . .
. . . . P . . .
. . . . . N . .
P P P P . P P P
R N B Q K B . R
Related
These are some expressions that I need to simplify. I've done what I can think to do, but surely they don't all simplify to themselves? Some expertise or guidance would be much appreciated.
for R.R = Z
logically, it's equivalent to R = z and you can prove that by the truth table
R
R.R
0
0
1
1
as its logical equivalent is a same input to 2-input AND gate. which will always give the input.
for R.S + R.S = T
you proved it correctly.
for X(bar) + X(bar) . X(bar) = K
X(bar) + X(bar) . X(bar)
= X(bar) . (1 + X(bar)) // since (1 + anything = 1)
= X(bar) . (1) // since (1 . anything = anything)
= X(bar)
then X(bar) = K
for X(bar) . Y(bar) . X(bar) . Y(bar) = P
X(bar) . Y(bar) . X(bar) . Y(bar)
= X(bar) . X(bar) . Y(bar) . Y(bar)
= (X(bar) . X(bar)) . (Y(bar) . Y(bar)) // since anything . anything = anything (proved from the truth table at the first one)
= X(bar) . Y(bar)
then X(bar) . Y(bar) = P
Basically, in a graph where the weights are the Euclidean distance, is something like Dijkstra's algorithm really necessary or is a direct path to your destination always the shortest?
I'm really asking for a general answer to this question, however I think this is always true for the case given below.
==================================
I'm almost 100% sure that this is the case if the edges form regular polygons.
These paths have no dead ends, i.e., there exists some path from any vertex v1 to any other vertex v2.
By regular polygon I mean the graph is formed by edge connection of regular polygons of n vertices, without ever forming other polygons in the process.
n = 5
. .
. .
. .
. .
. .
. .
. .
n = 4
. . . .
. . . . .
. . .
. .
n = 3
. . .
. . . . . .
. . . . . .
This may be a counterexample:
n = 4
. . . . . . . .
. . . . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . . .
Basically, if there is any non-symmetrical gap in the graph, then the greedy algorithm, which always selects the nearest vertex to the end vertex, may select a vertex which forces it to take a longer path.
However, the greedy algorithm will always work for paths with no obstacles, or paths with symmetrical obstacles if the starting point halves the obstacle. In fact, an algorithm which could simply find the shortest path around each individual obstacle would provide solutions nearly as good as Dijkstra's without as much overhead, as long as there are no dead ends.
But implementing such an algorithm is the same as implementing Dijkstra's on sub-paths of the total path, and is therefore pretty pointless, unless you really need to reduce the computational resources required.
I have a simple game where you can move a game piece 1 square vertically or horizontally in a grid to make a row of three pieces of the same type.
The game grid is 8 squares wide and 7 squares high, I want to find the most efficient way of checking if there are no moves left which will result in 3 in a row.
What I have so far is :
http://i.imgur.com/jY6wJvZ.png
My thinking is to test horizontally I just need to check column C isn't the same piece type as either side and the same for column F.
Vertically - I thought row 2 only needs to be compared with row 3 to make sure nothing matches and column 5 should be compared with rows 4 and 6 for matches.
So if none of those match then there can't possibly be any more moves?
I'm not sure if this is the most efficient way or if it could miss possible matches, can anyone with a better brain than mine please point me in the right direction?
Your check does not guarantee that there are no moves. For example, suppose the top-left corner were:
* *
a a b c . . . .
* c c a b . . . .
b b d a . . . .
. . . . . . . .
* . . . . . . . .
. . . . . . . .
. . . . . . . .
Indeed, no cell in column C is equal to either left or right of it, and no cell in row 2 is equal to either above or below it. Yet, we can swap C1 and C2 to create a 3-in-a-row.
As #Patashu suggested, a naive solution may be best here, especially for conceptualization, e.g. if someone else were to read your code. I would track three cells at a time (in a bounded FIFO queue), first by rows, then by columns, and when two of the three match, check the 2 to 6 surrounding cells that can possibly be swapped into filling the third. For example,
. . . . . . . .
. . * . . * . .
. * . a a . * .
. . * . . * . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
or
. . . . . . . .
. . . . * . . .
. . . a . a . .
. . . . * . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
or
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . * . .
. . . . * . a a
If any of these *'ed cells match (e.g. a), then you know another 3-in-a-row is possible.
Here's my naive algorithm. Obviously all array access should respect bounds checking.
1) Check each checkboard colour of the grid, as in xs only then .s only in the following pattern:
x.x.x.
.x.x.x
x.x.x.
.x.x.x
Scan it in reading lines (every x horizontally, then descend a row) (hint: % 2 and * 2 will be your friend here) doing the following:
1a) If the current tile is the same colour as the tile one lower and to the right of me, if any of the following Xs are also the same colour, that's a three in a row:
.....
..XX.
.Xx.X
.X.xX
..XX.
1b) For one lower and to the left is similar:
.....
.XX..
X.xX.
Xx.X.
.XX..
(I would encode the positions of the Xs as offsets from the central tile you are checking - as in an array like {0, -1},{-1, 0},{-1, 1} etc)
(Alternatively, you could implement each as a 5 by 5 array of 1 for check here, 0 for don't - similar to how it looks in this answer - and then scan the 5 by 5 array while scanning the play field. This might be faster. No idea! You'd have to test.)
2) Now descend down every column, top to bottom If two adjacent tiles are the same colour, check the tile two higher or three lower - if either is the same colour, that's a three in a row:
.
X
.
x
x
.
X
3) Similar for rows, reading left to right:
.X.xx.X
Note: I have no idea if this is faster than the naive algorithm of checking every possible swap to see if it makes a three in a row! After all, both algorithms are O(n^2), so which is faster will depend on implementation details. As such I recommend two things:
1) Don't optimize until you've implemented a solution, and the solution is too slow for the real cases it is being used in, for the people who are using it.
2) When you optimize, check that you made it faster! (And also make sure it still works - nothing is worse than an optimization that breaks code :) )
Of course, this doesn't mean that optimization isn't fun, but don't be fooled into thinking optimizing already fast enough code is doing anything but exercising your mind ;)
The generic goal
Say we have a "small" 10x10 grid with some fixed nodes # placed at random positions
. . . . . . . . . .
. . . . . . . . . .
. . . # . . . . . .
. . . # . . . . . .
. . . . . . . . . .
. . . . . # . . . .
. . . . . . . . . .
. . . . . . . # . .
. . . . . . . . . .
. . . . . . . . . .
And say we have ~30 nodes whose value is a function of what nodes it's adjacent to (with adjacency being defined as any of the 8 points surrounding a spot). That is to say, if we consider nodes A and B placed on the map
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . A # . . B . . . . . A # . . . . . .
. . . # . . . . . . . B . # . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . # . . . . . . . . . # . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . # . . . . . . . . . # . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
the output of both A and B may be different in these two maps because A and B are adjacent in the second but not in the first.
Our goal is to place all the nodes on the map in such a way that the sum of all nodes is maximal (or at least pretty good.)
Additional constraints for my particular problem
There are about 8 'classes' of nodes. All nodes in each class behave the same, so this can be used to reduce the search space.
Certain nodes dominate the overall value, so knowing this allows me to optimize around these core nodes.
Each node usually only has two or three other classes of nodes that increase it's value when it's adjacent to a node of those classes.
All values are ≥ 0.
I'd like to find good fits in a matter of seconds.. so there's some room for computation, but a pretty good solution in 5 seconds is better than a perfect solution in 2 days.
Naive greedy approach
What I'm doing right now is taking a simple greedy approach, then fine tuning the result.
I look at all the places on the grid and consider it for all the nodes that I haven't placed yet, and pick the best placement that I find. If there are multiple "best" positions, I pick one at random. I do this until all nodes have been placed.
After this initial process, I then pick a node at random and try and find a better place for it by looking at all open spots. I consider the effect that moving the node has on the node itself, as well as it's adjacent neighbors, so I don't move it if it's already in the best place overall. I do this a few thousand times to "fine tune" my layout.
Because of the random factors, I can get very different outputs given the same inputs, so I perform this process several times and take the best result.
The question
How can I do better than this naive greedy approach?
I feel like there should be a much better solution that takes into account a priori adjacency information, but it is eluding me. Any thoughts, links, or tips would be greatly appreciated!
I've worked on an algorithm for something similar-ish recently.
The idea :
We want to restrict our options in order to gain computation time (that was my problem cause i've done it in 3D)
It seems logical in your case that you want to place nodes next to already placed nodes.
Let's mark p the possibilities.
. p . . . . .
p # p p . . .
. p p # p . .
. p # p . . .
. p p . . . .
p # # p . p .
p p p . p # p
Initialization:
Let's call "Cluster" an array which contains possible places.
Here it's the array with all p
For each node that you need to place you find the best option among those p;
So for each new node you got something like Node::(place & value)
Iteration:
You place the best node , that will remove 1 possibility in the Cluster and add some (depending on already surrounding nodes)
Now you want to update the best place & value for each node.
But you can work on the few modified nodes because every other possibility is already computed :
. p . . . . . A : recently placed
p # p p . . . C : new possibilities / possible changes
. p p # p . .
. p # p . . .
. C A C . . .
p # # p . p .
p p p . p # p
Here for example only 2 computations are necessary for each node left.
If the new value is greater => change the (value & position)
Iterate.
Possibilities of errors:
I can't tell if this will work perfectly with your problem because i got no way to know if a "bigger" value need to be placed first or not but i guess so.
This solution will not be the perfect one but should be a correct one if your values are linear or almost linear in the number of surrounding pores.
I can't find a way to say that in english but in french i call this kind of algorithm "Algorithme de progression de front" which is something like "Front-Progress Algorithm".
Maybe can you find something based on that but i didnt after a quick search.
I hope that it helped you.
I am looking for an algorithm that will describe the transient behaviour of a fluid as it spreads across the surface of a height map. My starting conditions at t=0 are:
A 2D matrix of height values (H) of size [x, y]
A 2D matrix of fluid height values (F) of size [x, y]
A metric of the area of each point in the matrix (a), i.e. each location is 1 cm^2
A viscosity value for the fluid (u)
What I want is an algorithm that can calculate a new value for the fluid height matrix F at t'=t+1. At any point I could calculate the volume of fluid at a given point by v = a * (F(x,y) - H(x, y)). Desirable properties of this algorithm would be:
It does not need to consider the "slope" or "shape" of the top or bottom of the fluid column at each point. i.e. it can consider each value in the hieghtmap as describing a flat square of a certain height, and each value of the fluid height map as a rectangular column of water with a flat top
If a "drain" (i.e. a very low point in the height map) is encountered, fluid from all parts of the map may be affected as it is pulled towards it.
A simple example of what I'm looking for would be this:
A 5x5 height map matrix where all values are 0
A 5x5 fluid height map matrix where all values are 0 except [2, 2], which is 10.
An area per point of 1 m^2
A viscosity of u
The algorithm would describe the "column" of fluid spreading out over the 5x5 matrix over several time steps. Eventually the algorithm would settle at a uniform height of 10/25 in all locations, but I'm really interested in what happens in between.
I have attempted to search for this kind of algorithm, but all I can find are equations that describe the behaviour of particles inside of a fluid, which is too granular for my purposes. Does anyone know of any good sources I could reference for this problem, or an existing algorithm that might serve my needs.
O is your starting fluid-column
o are diffusing columns
************************
X X X X X
X X X X X
X X O X X
X X X X X
X X X X X
************************
--Get the Laplacian of the heights of each neighbour and accumulate results
in a separate matrix
--Then apply the second matrix into first one to do synchronous diffusion
--go to Laplacian step again and again
************************
X X X X X
X X o X X
X o O o X
X X o X X
X X X X X
************************
************************
X X . X X
X . o . X
. o O o .
X . o . X
X X . X X
************************
************************
X X . X X
X o o o X
. o o o .
X o o o X
X X . X X
************************
************************
X X . X X
X o o o X
. o o o .
X o o o X
X X . X X
************************
************************
X . o . X
. o o o .
o o o o o
. o o o .
X . o . X
************************
************************
. . . . .
. o o o .
. o o o .
. o o o .
. . . . .
************************
************************
. . . . .
. . . . .
. . o . .
. . . . .
. . . . .
************************
************************
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
************************
sorry for very low height-resolution
Laplacian
Laplacian's place in diffusion
Diffusion's place in Navier-Stokes equations
Discrete Laplace Operator
Simple algorithm (in pseudo):
get a cell's value in a.
get neighbour cells' values in b(sum of them)
put b/4.0 in c(getting 4 cells' values)
add a to c
build a matrix with this algorithm
apply the matrix onto old one
goto step 1
Harder algorithm (in pseudo):
apply discrete-Laplacian-operator on all neighbours(finite-differences thing)
put solution in c height-map
subtract or add c to/from starting height-map
goto step 1
Jos Stam's fluid-solver has a similar thing for the diffusion part.