Engine release: weiss

[Guenther]

No popcount compilation of current 0.7 dev from 22-11-2019 for older 64 bit hardware:

http://rwbc-chess.de/Downloads/Engines/Weiss_07-64n.7z

[Terje]

I compiled a non popcount version today from current 0.7 dev master w/o problems.
If someone needs it I will add it for download.

First I thought though something was wrong with my compile because it sent only a1a2 or a1b1 pvs in cmd
until I realized it needs the 'position startpos' command too
Oh and it did not work with HGMs UCI2WB adapter in Winboard (reason not checked yet), but with Polyglot.

BTW it does not tell it has correctly found the syzygy tables, if given, as most programs do.
I needed a few games to see tb hits in the log. The score is also unusually low if syzygy tables are already on the board.
In the little test game which finally showed tb hits, the position after 54...Kxa5 leaves a 5men position (syzygy 5 were used),
but the eval remained around the same as before for several moves between +15 and +16.

The raw search speed is ofc tremendous as Dann already said, this was visible even on my old quadcore w/o popcount
and just SSE4.1.

...

The UCI protocol specifies that a search shall be initiated by a combination of position and go; "the next search (started with "position" and "go")". I can make it less strict if that's convenient tho of course!

I will add an indication that tablebase init was successful.

So far in development I've assumed that if weiss plays with tablebases there is tablebase adjudication; I don't see any reason to keep playing if the engines have an oracle telling them what do to, the result is already determined. In local testing I use 6men for both. I have not yet implemented DTZ to pick moves or anything, so after reaching a tablebase position weiss will be clueless what to do to actually progress towards the win (aside from avoiding 50mr maybe?), picking any move that leads to another tablebase position that is still won.

Thanks a lot for the feedback and the compile!

[Guenther]

So far in development I've assumed that if weiss plays with tablebases there is tablebase adjudication; I don't see any reason to keep playing if the engines have an oracle telling them what do to, the result is already determined. In local testing I use 6men for both. I have not yet implemented DTZ to pick moves or anything, so after reaching a tablebase position weiss will be clueless what to do to actually progress towards the win (aside from avoiding 50mr maybe?), picking any move that leads to another tablebase position that is still won.

Thanks a lot for the feedback and the compile!

There are several reasons to test w/o adjudication by tablebases. One of them is that e.g. the opponent cannot use tablebases,
thus it might lose positions which are draw.
Another one is, that this might hide serious bugs in endgames, e.g. not being able to mate with KQ or KR vs. K, all this has already
happened with several programs in the past.

Of course, if both programs support tablebases adjudication at a certain point is useful and convenient, but you never know
if testers have some other reasons not to do so and which tablebases they use (size).

Thanks for your program and good luck with further progress :)

[Gabor Szots]

The engine introduces itself as v0.5, is that right? The package name is v0.6.

Oops, I forgot to update that. It should say 0.6.

You seem to develop the engine in a fast pace, you are already at version 0.7. When do you think your engine will be ripe enough to include it in our testing?

[Terje]

The engine introduces itself as v0.5, is that right? The package name is v0.6.

Oops, I forgot to update that. It should say 0.6.

You seem to develop the engine in a fast pace, you are already at version 0.7. When do you think your engine will be ripe enough to include it in our testing?

It's now 0.7-dev, the next release will be 0.7. I think you could include it already (0.6) if you want to

As for the TB adjud hiding errors, weiss training games are done without any TBs (for engine or adjud), and it plays reasonably there I believe although it's been a while since I've actually watched a TBless game :p

[Gabor Szots]

It's now 0.7-dev, the next release will be 0.7. I think you could include it already (0.6) if you want to

OK. BTW, you are from Norway, aren't you? We like to include nationality in our database.

[Terje]

It's now 0.7-dev, the next release will be 0.7. I think you could include it already (0.6) if you want to

OK. BTW, you are from Norway, aren't you? We like to include nationality in our database.

Yes

[Gabor Szots]

I allocate 256 MB hash for the engine but by the end of the game its memory allocation reaches almost 2 GB. Probably because of syzygy bases but I am afraid my 8 GB RAM won't like it.

[Terje]

I allocate 256 MB hash for the engine but by the end of the game its memory allocation reaches almost 2 GB. Probably because of syzygy bases but I am afraid my 8 GB RAM won't like it.

Is that playing a lot of moves after reaching a tablebase position or something? Locally I test with 1024MB hash, and have only ever seen it sit around 1053MB total in task manager.

[Gabor Szots]

I allocate 256 MB hash for the engine but by the end of the game its memory allocation reaches almost 2 GB. Probably because of syzygy bases but I am afraid my 8 GB RAM won't like it.

Is that playing a lot of moves after reaching a tablebase position or something? Locally I test with 1024MB hash, and have only ever seen it sit around 1053MB total in task manager.

Yes, although I do not know if it was a TB position because there were still many pieces (I think 10) on the board.

EDIT: Now again, around move 75 with 11 pieces the memory started to grow. At move 100 there were only 4 pieces and the memory saturated at about 1 GB.