Houdini 1.02

[Matthias Gemuh]

Robbobases are a real mess:

- they need far more RAM than Gaviota EGTB.
- only few people can configure Robbobases correctly
- Robbobases are a bit buggy (see only draw in some winning endgames)
- Gaviota EGTB have bitbases also
- Gaviota EGTB are used by increasingly more engines.

Is there any way to download only 3-men Robbobases and have only 16 MB memory allocated for them ?
That is perfectly possible with Gaviota EGTB.

Matthias.

[TheKnilch]

unless he has multiple machines running?

you got it.

[Roger Brown]

That is of course if you can get permission to use EGTB?

Hello Harvey,

Gaviota tablebases need no special permission.

That development is a smashing step forward, Miguel is to be congratulated.

The EGTB field has opened up.

Later.

The Gaviota Tablebases can be probed from your own program (engine or interface). The code has been released under the liberal MIT license, so basically anybody can use it with almost no restrictions.

[Harvey Williamson]

That is of course if you can get permission to use EGTB?

Hello Harvey,

Gaviota tablebases need no special permission.

That development is a smashing step forward, Miguel is to be congratulated.

The EGTB field has opened up.

Later.

The Gaviota Tablebases can be probed from your own program (engine or interface). The code has been released under the liberal MIT license, so basically anybody can use it with almost no restrictions.

That's ok then as I am sure they contain no Nalimov code.

[Roger Brown]

Robbobases are a real mess:

- they need far more RAM than Gaviota EGTB.
- only few people can configure Robbobases correctly
- Robbobases are a bit buggy (see only draw in some winning endgames)
- Gaviota EGTB have bitbases also
- Gaviota EGTB are used by increasingly more engines.

Is there any way to download only 3-men Robbobases and have only 16 MB memory allocated for them ?
That is perfectly possible with Gaviota EGTB.

Matthias.

Hello Matthias,

Gaviota EGTB are used by increasingly more guis.



Later.

[LetoAtreides82]

Currently just 4 elo under Rybka 4 in the Ipon tournament, and their respective matchup is currently 50%. It's almost like their identical in strength.

[yanquis1972]

Currently just 4 elo under Rybka 4 in the Ipon tournament, and their respective matchup is currently 50%. It's almost like their identical in strength.

yes, this is what i've been saying. it's really quite exciting and considering the facts of BBs presentation, ippolit open source code available to anyone, & M Houdart actually attaching a name &, hopefully, face & body at somepoint to the author of the engine. the fact that two such engines, so far above their field, could so close in strength is somewhat remarkable. given consistent improvement houdini should be a fantastic analysis partner/counterpart to R4 in no time.

[LetoAtreides82]

Just finished my first 100 games for my private CEGT Blitz testing of Houdini 1.02, now creating the rating list.

[BB+]

Houdart: The use of EGTB is part of the strength of an engine, so it's probably fair that EGTB are used for the test.
How did you estimate the +10 to +20 Elo strength improvement from EGTB?

VR has always said it is much less (like 2 ELO), and he got that from fixed depth testing (I think this methodology is bad, however, as EGTBs can reshape the tree a lot, and introduce new prunings). However, Nalimov and bitbases are two different things, even if Nalimov is on a fast solid-state drive. At some point, I tracked down the CCRL data for bitbase usage with Shredder and Toga/Scorpio (though I think Shredder's version is superior --- in fact calling these both "bitbases" is a bad idea to me, as the access is completely different --- Shredder uses what I presume is a run-length encoding and never "decompresses" anything into memory per se, while Scorpio essentially imitates the Nalimov method and so needs to have blocks of memory set aside for that, and do Huffman decoding over 8K blocks, rather than run-length decoding over short segments). The numbers ranged from 10-25 ELO. I think there was a claim that the RobboBases added about 10 ELO in fast self-play games (I actually think self-play could underestimate the difference here, as the game is more likely to be drawn before the endgame is reached). Of course, for any given engine it depends on how good/bad its non-EGTB endgame play is.

Gemuh:
- they need far more RAM than Gaviota EGTB.
- only few people can configure Robbobases correctly
- Robbobases are a bit buggy (see only draw in some winning endgames)
- Gaviota EGTB have bitbases also
- Gaviota EGTB are used by increasingly more engines.

I must be one of the few people in #2, I guess, though admittedly I use Linux rather than Windows, and I agree that the help for this could be superior.
I think your first point is a misnomer, as the whole point of RobboTripleBases seems to be that they are meant to be "instant access" because they fit in memory (like ShredderBases), and don't have to be loaded from the disk. You can change the RobboBase code to use the "TotalBases" from disk instead (I don't know how easy this is to do -- maybe just change TRIPLE_VALUE in evaluation.c to RobboTotalBaseScore), and I suspect it will become somewhat slothful, just like disk access with Nalimov. As a reverse aspect to the larger RAM for the TripleBases, you can note that the TotalBases take less disk space (by a significant margin) than Gaviota or Nalimov (even less than FEG, largely because Robbo uses one-sided DTC).
When Ballicora first released his TBs, I did a few timings, and the RobboTripleBases were much faster, largely because of the disk access issue I think. The above nuance between types of bitbases puts Gaviota into the Nalimov/Scorpio class (I think), while to me the checkers/Shredder class is the superior one. Perhaps the best solution would be to allow the user to pre-load desired bitbases into RAM and have others load on-demand from the disk (loading bitbases would be more efficient than loading TotalBases from the standpoint of I/O throughput, though either is possible). As for your last point, I see no reason why you can't support more than one option.

Is there any way to download only 3-men Robbobases and have only 16 MB memory allocated for them ?

I must be missing something --- surely the 3-men TripleBases will fit into about about 25K? The 4-men fit into about 4MB.

[BTO7]

Currently just 4 elo under Rybka 4 in the Ipon tournament, and their respective matchup is currently 50%. It's almost like their identical in strength.

yes, this is what i've been saying. it's really quite exciting and considering the facts of BBs presentation, ippolit open source code available to anyone, & M Houdart actually attaching a name &, hopefully, face & body at somepoint to the author of the engine. the fact that two such engines, so far above their field, could so close in strength is somewhat remarkable. given consistent improvement houdini should be a fantastic analysis partner/counterpart to R4 in no time.

I agree Yan ...it is good to have a guy like Robert putting a name and face for IPPO source. Just as amazing and you may not know. The authors of the IPPO source are too on their own mission. This is kinda of a neat post at the IPPO site explaining their goal and focus too and i quote ...

"Decembrist-57703 Yesterday 3:00 am
jc.m, the focus of IPPOLIT is to make a great chess player. We make it build on our machines, and let you worry about yours. We don't want to get bogged down in a time consuming maintenance of a repository and building on multiple platforms. Making it ISO compliant is not our priority, but you are free to take it and do it if you want.
Our Makefile shows clearly we use -Wall, but even gcc gives more errors than necessary. Most of the VS2008 warnings are superfluous. The valgrind we had didn't support POPCNT, but we used it a couple of times. We don't bother to free memory at quitting time as the OS can do that."

I find this interesting that while guys like Robert are fine tuning the sources with great success ....IPPO's main goal is to just source a great chess player. This is what I like about the IPPO team. Seems they are great programmers its a one for all and all for one attitude in which its not about the money as much as it is about a great chess player. Team is felt over there I'm seeing a different philosophy over there that is more just purely about the love of the game being most important. I like to see what happens when people work together like this in any field.

Regards
BT