New version of HaChu released

[hgm]

I uploaded a new version (0.11) of my Chu Shogi engine HaChu, to http://hgm.nubati.net/HaChu.exe . It is hugely improved compared to previously reased versions 0.7 and (three days ago) 0.9. Which was not difficult, as 0.7 was in such an early stage of development that it could hardly be called an engine. (Just a fixed-depth alpha-beta searcher without anything, not even a decent QS.) Version 0.11 starts to deserve that name, however. It contains the following improvements compared to 0.7:

*) Pondering (not tested for Elo, but includes analysis mode as a spin-off)
*) True Quiescence Search (added 190 Elo)
*) Tsume-mode option (checks-only search for mating problems)
*) Hash table (added 170 Elo)
*) End-game evaluation added and interpolated with old (opening) eval (added 100 Elo)

Especially the latter completey changed its playing style: it tries to trade away the opponents's easily promoting (slider) pieces (which have end-game values nearly equal to their promoted types) for its own difficult-to-promote material, and then agressively tries to trade down to a phase where promotions become possible.

Still no killer heuristic, null-move or LMR however.

The Elo gains were measured with only 100-200 games, and have a large error margin. (But for gains this large that was good enough.)

[Graham Banks]

Would love to see a new version of Joker.

[hgm]

You can forget about that. I stopped development of Joker in 2008. Spartacus is already stonger with only a fraction of the game-specific knowledge Joker contained, even though it is only half finished.

I have been working on a 'turbo version' of Fairy-Max, though, which is nearly finished. But until the ICGA meeting in August I won't have much time for orthodox Chess.

[Graham Banks]

You can forget about that. I stopped development of Joker in 2008. Spartacus is already stonger with only a fraction of the game-specific knowledge Joker contained, even though it is only half finished.

I have been working on a 'turbo version' of Fairy-Max, though, which is nearly finished. But until the ICGA meeting in August I won't have much time for orthodox Chess.

Looking forward to Spartacus then.

[hgm]

Well, after August, perhaps.

Although I might want to write a new engine first, that can run in only 24KB of RAM. But that cannot take very long.

[hgm]

Now HaChu 0.12 is available from the same link.

*) killer heuristic (added ~80 Elo)
*) some minor eval additions (which surprisingly seem to add something similar)
*) repaired 'undo' when starting from a setup position
*) option to switch hash cuts in PV nodes on/off in analysis mode

[zullil]

Now HaChu 0.12 is available from the same link.

*) killer heuristic (added ~80 Elo)
*) some minor eval additions (which surprisingly seem to add something similar)
*) repaired 'undo' when starting from a setup position
*) option to switch hash cuts in PV nodes on/off in analysis mode

HaChu needs an opponent. Gesundheit 0.1?

[hgm]

Actually lack of opponents is a great hindrance in testing. Especially if you don't even play the game yourself, so that you would not notice gross blind spots.

I am challenged to appear with HaChu in the ICGA Olympiad, (and will of course accept the challencge as I am going there anyway), so there will be an opponent! Not sure if it will be public, like HaChu, though.

[Henk]

I uploaded a new version (0.11) of my Chu Shogi engine HaChu, to http://hgm.nubati.net/HaChu.exe . It is hugely improved compared to previously reased versions 0.7 and (three days ago) 0.9. Which was not difficult, as 0.7 was in such an early stage of development that it could hardly be called an engine. (Just a fixed-depth alpha-beta searcher without anything, not even a decent QS.) Version 0.11 starts to deserve that name, however. It contains the following improvements compared to 0.7:

*) Pondering (not tested for Elo, but includes analysis mode as a spin-off)
*) True Quiescence Search (added 190 Elo)
*) Tsume-mode option (checks-only search for mating problems)
*) Hash table (added 170 Elo)
*) End-game evaluation added and interpolated with old (opening) eval (added 100 Elo)

Especially the latter completey changed its playing style: it tries to trade away the opponents's easily promoting (slider) pieces (which have end-game values nearly equal to their promoted types) for its own difficult-to-promote material, and then agressively tries to trade down to a phase where promotions become possible.

Still no killer heuristic, null-move or LMR however.

The Elo gains were measured with only 100-200 games, and have a large error margin. (But for gains this large that was good enough.)

Are you sure about the 170 ELO of the hash table. This means that my hash table implementation or usage was truly bad. I removed the hash table
or transposition table from my program and I didn't notice much difference.

The first problem I encountered with the hash table was that I did not know what to do when Hash gives back an upper bound and you search a position with an artificial lower bound greater than that upper bound from hash.

[hgm]

Are you sure about the 170 ELO of the hash table. This means that my hash table implementation or usage was truly bad. I removed the hash table
or transposition table from my program and I didn't notice much difference.

Well, this was measured with between 100 and 200 games, so the error bars are huge (like +- 70 Elo for 95% confidence and 100 games). But good enough to prove there is significant gain, and to prove to my satisfaction that I did not mess up the implementation.

Note, however, that how much a feature adds depends a lot on what other features you already have. Hash was one of the first things I did, so the engine had very little for move sorting, (just captures first, no killer), so searching a hash move first is a much bigger help than when it already has all kind of clever heuristics to pick good moves. Furthermore the IID gets very inefficient without hash, as in the next root iterationit would not automatically find all results just one depth short of what it needs, so it really starts to iterate from d=1 up.

The first problem I encountered with the hash table was that I did not know what to do when Hash gives back an upper bound and you search a position with an artificial lower bound greater than that upper bound from hash.

That is the good case, right? If the hashed result is an upper bound below the node's current alpha, you know for sure the real score must be below alpha, hence a fail low. So you cut off using the score if the depth was sufficient.

What I do on probing is very simple: if the bound type is usable for the current window I use the hashed depth d as a starting point for IID (i.e. I start IID at d+1, because the TT already gave me d). If d+1 is greater than the requested depth this means I am done, so the score is returned without any searching. If the bound is not usable I use the hashed move (if there was any) to sort in front, but I start IID at d=1.