On 20/08/12 12:34, Jim - FooBar(); wrote:
On 20/08/12 10:12, nicolas.o...@gmail.com wrote:
(defn generate [board next-boards]
;; next-boards return a seq of MoveAndBoard
(BoardAndChildren. board
(r/map (fn [m]
(MoveAndTree.
(:move m)
(generate (:board m)
next-boards)))
(next-boards board))))
should work better.
Good morning Nicolas,
well, I did play around with your code and I think I spotted the
problem...
You see if I isolate this line (from 'best-move'):
(into [] (r/map (fn [m] {:move (:move m) :value (search score-by-count
(:tree m) dir d)})
(:children (generate b dir next-boards))))
I do get back a vector of these (yay!):
{:move #Clondie24.lib.core.Move{:p
#Clondie24.games.chess.ChessPiece{:image #<BufferedImage
BufferedImage@232412bc: type = 6 ColorModel: #pixelBits = 32
numComponents = 4 color space = java.awt.color.ICC_ColorSpace@154a06aa
transparency = 3 has alpha = true isAlphaPre = false
ByteInterleavedRaster: width = 50 height = 50 #numDataElements 4
dataOff[0] = 3>, :position [0 6], :rank pawn, :value 1, :direction
-1}, :mover #<core$partial$fn__4107
clojure.core$partial$fn__4107@5bd5efae>, :end-pos [0 4]}, :value nil}
so yes, the recursion works just fine and actually surprisingly fast
(less than 5 sec for level 4)...However you will notice that the
:value key for the move is always nil! consequently, when I add this bit:
(apply max-key :value
... ... ... )
I get the aforementioned exception (from last night). It seems that
'my-max' and 'my-min' produce nils that max-key cannot deal with!
(defn my-max
([x y] (if (nil? x) y
(if (nil? y) x
(max x y))))
([] nil))
(defn my-min
([x y] (if (nil? x) y
(if (nil? y) x
(min x y))))
([] nil))
'max-key' does look like the perfect candidate for this job but
unfortunately I can't get it to cooperate with reducers! Problem...
Jim
Ok I spotted the problem...IT turns out the blame does not fall on
'max-key' ! The problem is that recursion does not go all the way down
to level 0 so it can finally evaluate the leaves. For some very strange
reason recursion only goes 2 levels down!!! Here is the recursive fn:
(defn search "The recursion of min-max algorithm."
[eval-fn tree dir depth]
(letfn [(minimize [tree dir d] (do (println d)
(if (zero? depth) (eval-fn (:board tree) dir)
;never reaches here
(r/reduce my-min
(r/map #(maximize % (- dir)
(dec d)) (:children tree))))))
(maximize [tree dir d] (do (println d)
(if (zero? depth) (eval-fn (:board tree) dir)
;never reaches here
(r/reduce my-max
(r/map #(minimize % (- dir)
(dec d)) (:children tree))))))]
(minimize tree dir depth)))
As you can see I'm printing the depth at each level...To my surprise,
when I start it with 8 it prints :
8 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 7 7 7
7 7 7 7 7 7 blah blah blah... and stops at 7 where it does return a
move but with :value nil! It doesn't go any depper than that! What on
earth is happening? Since it never reaches level 0 , it never gets to
evaluate the leaf boards so that is where nils come from! In your code
you had something like this for recursion:
(let [^double res
(r/reduce my-max
(r/map
#(- (tree-value (:tree %) evaluate (dec depth)))
(:children tree)))]
(if (nil? res) (evaluate (:board tree)) res))
However, here you're not checking for depth - you're only checking for
when r/reduce returns nil which apparently happens after going down 2
levels.
Is this happening because of r/map? I don't get it!!!
any pointers anyone?
Nicolas, when you posted the code, had you checked that recursion goes
all the way down to the leaves?
Jim
--
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