broken?

[abik]

mate thread

Uh, too late to edit. That should be "mate threat". A hopefully understandable typo in this context

[bpfliegel]

I'm not so sure about that. My C# engine used to allocate Lists, Moves, and everything else in accordance with OOP principles, and speed wasn't really a problem. However, the memory use was troubling, as it seemed like the GC gave up on it.

If you allocate several million objects per second, this puts a lot of stress on the GC and at the end this will turn into a huge performance penalty. In case of Portfish I remember that switching off the object pooling (and allocating every them instead of reusing) degraded the performance ratio against the original (Stockfish) from 1:2.7 to 1:6.8. I'm very confident that object pooling is a must in .Net and very likely in Java aswell.

Maybe, it should be also noted that if you implement a vanilla alpha-beta/negamax your engine will do everything to dodge a mate in 1 when winning At least that happened to me - was funny to see 6 queens on the board with a clueless king. Described here: http://home.hccnet.nl/h.g.muller/delay.html

Balint

That anomaly of looping around in won-situations may indeed occur while forced mate possibilities remain after the selected not-directly-mating-move, and adding delay penalties will fix that. However, in my simple example, many responses from white on a black move resolve the mate thread altogether, and not finding that even with vanilla alpha-beta seems a bug to me.

Yes, I think there should be other problems first to resolve. In case you play against Neg03d and see a lot of queens, you should feel fine that mate delay is probably the last bug you have

[abik]

As suggested by all the others, I would indeed also look in avoiding object allocation inside your movegen/search. While running DeepBrutePos for Android on the Dalvik VM, I see an excessive number of garbage collection calls. The built-in engine of Chess for Android is written in Java as well (it is actually a stripped-down derivative of BikJump ported to Java) and I don't have a single object allocation inside the core move generator and search methods. That makes a very big difference!

[flok]

http://vanheusden.com/DeepBrutePos/Deep ... rc.tar.bz2

The move-generator and such has played almost 100.000 games on fics now with 0 crashes and 0 illegal moves.

You have ensured your perft numbers are correct, right?

Your site says you have some sort of experimental evaluation.

Not yet! First I want to the brute-force-code to perform a bit, then I'll add my special evaluator.

Java has LinkedList and ArrayList (c++'s vector). He's probably using the latter.

Yes!

Forget about "making it faster" as long as it is not clear whether your search algorithm is even implemented correctly. Here I mean "correct" in the sense of correctly using alphaBeta, not in the sense of not playing illegal moves in the game.

Will it work if I start crafty without book, and then enter e.g.:
new
easy
depth 4
e4
a4

and then verify that with my program?

Now my next questions:
a) What is your typical value for "maxExtension"? May I guess "-1" or "-2"?

-5 actually!

b) What is the meaning of:

Code: Select all

      if (score == -Integer.MAX_VALUE || score == Integer.MAX_VALUE)
         continue;

i.e. in which case does your evaluation function (getShannonValue()) return MAX_VALUE (positive or negative), and how does getShannonValue() know when to return the positive or the negative MAX_VALUE?

Historical garbage: getShan. should (no longer) return that.

c) You still have the same "suspicious" call of validateMoves() after making a move. Last time in January 2012 you tried to explain what that function does but that blew my mind. So has anything changed substantially since then in that area, or do you still do it the same way?

It is still there, sorry
The problem is that Pos (both versions) does move generation a bit different. No bitboards, null-moves, etc. So implementing your suggestion is a bit of a challenge. I'm trying as much as possible to improve my program without (unless not possible) changing the design of it too much.
"Design?" you may ask? Yes, there's a design
Let me explain:

http://www.talkchess.com/forum/viewtopi ... 906#472906
The state is stored in two arrays; black objects and white objects. Each object "knows" its position, its type and wether it has done any moves.
Then each time a move must be calculated, a scene object is allocated. As parameter it gets the two arrays and a move (unless initial position). Then a board-object is created and filled in according these two arrays. Then the move is executed and then each chessobject is "asked" what moves it can do. The Scene object then goes through the list of moves for the "current player" and checks if a move puts the current player into check or let him stay in check - these moves are removed. The last step is invoking the Brain-object which makes up a move.
Each move-object has a scene-"pointer": that way if a move was calculated by the valid-move-validator, it is not neccessary to calculate it again in the a/b code.

Sven's code looks great, but I think I know why the original implementation doesn't work too well.

Code: Select all

return getShannonValue(scene, side);

should actually be

Code: Select all

return getShannonValue(scene, rootSide);

I remember having this problem when I first started.

Can be a cause but not the cause. Did a quick tournament on my phone and it succeeded in losing all 20 games.

[zongli]

Hye Folkert, I'm currently looking at the code you posted and will make give some thoughts on the new thread (there are lots of ways improve the code!). Can you verify that alpha-beta is working on some test positions (simple captures and mates)? Maybe provide a binary so we can take a look at its behaviour?

[flok]

Hi,

Hye Folkert, I'm currently looking at the code you posted and will make give some thoughts on the new thread (there are lots of ways improve the code!). Can you verify that alpha-beta is working on some test positions (simple captures and mates)? Maybe provide a binary so we can take a look at its behaviour?

A binary can be found here: http://vanheusden.com/DeepBrutePos/Deep ... 120709.jar

invoke with e.g.:

java -jar DeepBrutePos-1.6-20120709.jar --io-mode xboard

xboard can also be uci or console

Regarding the test positions: it looks like that the current a/b code is broken.
Crafty (with black):
e4 Nf6
a4 Nxe4

DBP - with 'eval with ply-side':
e4 Nf6
a4 Nd5

DBP - with 'eval with rootSide'
e4 e5
h7 h5