Then you didn't look close enough of my first message :)
Granted, I omitted large parts of the code in it but it showed my
evaluate function with pruning attached.
Here's my evaluate function, with debugging code cleaned:
(defn- evaluate-with-minmax
"Evaluates given game state with minmax-algorithm."
[depth eval-fn state]
(->> state
gametree
(prune depth)
(maptree eval-fn)
maximise))
In gametree I use my legal-states function to generate all resulting
states achievable from given state.
This takes should check draws etc. At least thats the idea.
Pruning should limit the gametree to given depth and maptree should
apply eval-fn to each node in the tree.
Though I'm still having some issues with my minmax.
When I'm trying to evaluate single state it returns a nil in about 1
msec.
Seems that there are some issues with laziness as the algorithm seemed
to work somehow when I printed the debug information.
If I have understood the minmax presented in hughes's work the
functions before maximise calls need to be lazy.
This should guarantee that the algorithm will only evaluate the stuff
it needs.
This is not that important in minmax as it will visit every node
anyway but is vital for the alphabeta version to work correctly.
Is it correct way to just wrap the function' s mentioned above in lazy-
seq calls and it should work or does it need something else?
My current code can be found in
https://github.com/zmyrgel/tursas/tree/master/src/tursas
Any ideas on improving the search.clj or overall the engine would be
appreciated.
It's kinda hard work as I haven't done any chess engine before nor
have I done any functional programming either.
I know I could have used tree-seq to make the search.clj code more
Clojure like but the Hughes's work was nicely explained and I didn't
know how to implement it in more Clojure-like way.
Timo
On Dec 6, 12:40 am, Ken Wesson <kwess...@gmail.com> wrote:
> On Sun, Dec 5, 2010 at 7:46 AM, Timo Myyrä <timo.my...@gmail.com> wrote:
> > Thank you, this solved the issues I was having as far as I can tell.
>
> > Now I can focus on getting rest of my chess engine working properly.
>
> Chess? Then you've got a problem. I didn't see any pruning or even
> depth bounding in your algorithm. And not only is searching the entire
> move tree in chess generally impractical, but making matters worse,
> there are some endgames that admit infinite sequences of moves (e.g.
> both players doing nothing but fiddling with their kings, forever).
> Sure, nobody would actually play those endgames -- they'd go on the
> attack, or one of the various rules that result in declaring the game
> drawn would kick in, but your algorithm will consider them anyway, and
> consider them, and consider them, and consid#<StackOverflowError>
>
> Looking on the bright side, though, it should now work for
> Tic-Tac-Toe. Or any other game that is guaranteed to run out of valid
> moves in finite time.
>
> For chess, though, you're going to have to implement bounding the
> depth of search and, if you want it to be really good, heuristic
> pruning.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
