TalkChess.com

Uri Blass wrote:

mcostalba wrote:

IWB wrote: OK, I think everything is right. ALL my computer have a Minimum Spilt Depth of 4 as I switch off HT by default and the Q6600 have it on 4 automaticaly of course! I assume that my testing was correct then ... right?

Yes, it is correct, but as clearly stated in the 1.7.1 announcement zugdetection is OFF by default and should remain OFF for offcial testing.

What probably was not clearly stated is that when you turn ON zugdetection the progam _could_ become weaker, not stronger.

So zugdetection is good for analysis or for study on some position, but on real games, at the moment, we suggest to turn it OFF.

IOW, please test 1.7.1 AS IS ! Do not change anything because default setup is the strongest.

I hope this is clear enough.

I do not understand how do you know that default setup is the strongest.

There are many parameters that people can change and people may find stronger setting espacially when you tested only at fast time control and it is possible that some different setting is stronger at slower time control and not at faster time control.

Uri

I am talking about official tests. I consider Ingo's one an official test and in this case are the engine developers that 'suggest' the best setup that usually is the default. And also in the case of 1.7.1 the suggested setup for offcial tests is to leave the default (of course modulo changing the number of CPU according to your machine).

We think that is the best, but it does not mean that it actually is, this is just what we suggest for offcial tests.

Hello Marco

Thx for the clarification!

I will test on then as everything seems to be right!

The biggest problem was that Zugzwang detection is weakening the engine, that was something I did not consider - when I read then about the Minimum Split point I was totaly confused ... but all turned out to be ok.

Thx again for the engine
Ingo

Hi

Yea, it seems that everything is all right. I am continuing with my testing!

Thx
Ingo

IWB wrote: The biggest problem was that Zugzwang detection is weakening the engine, that was something I did not consider - when I read then about the Minimum Split point I was totaly confused ... but all turned out to be ok.

You are right. I will try to explein why zug detection _could_ (because is still not proven 100% but our internal tests say so) weaken the engine.

When SF evaluates a position it stores the position score in a big table in memory called transposition table or hash.

If SF founds again the same position it does not search again through that, but simply uses the already saved position score. This saves a lot of searching effort. It is very common practice and almost all teh engines do the same.

In SF we save the position score _also_ when doing what is techncially called a null move search that is a kind of quick search to see if position deserves to be searched deeper or, being uninteresting, can be skipped.

This null move search is very powerful but has a weak point: it can fail when the position is zugzwang for the side to move. In this case the null search can give a wrong result and reports that the side to move is winning while it is not. Normally is not so dangerous, but if you save the wrong result in the hash table (as we do starting from 1.7), next time you find the same position you think you are still winning yielding to a completely wrongly evaluated position (I am not very precise here because otherwise the things would be a little bit messy, but the concept is this).

So, how zug detection works ?

With zug detection SF simply does _not_ saves in hash table the score for the positions found by null search, in this way you cannot mislead a zug position but at the same time you lose the benefit of having the position score already saved in the hash table and so your search effort is bigger: that's the reason why zug detection could weaken your engine (also in this case the description is not 100% accurate but gives the idea, actually SF saves the same the score but does not use it in certain cases)

Because real zug position happens very seldom in real games you end up with a bigger searching effort for no real benefit when you enable the zug detection.

I hope it is clear enough.

Hi Jim,

Could you please provide another d/l links for SF171?

Best,

Aaron Becker wrote:

Tord Romstad wrote:I have now prepared a GUI release of Stockfish 1.7.1 for Mac OS X. Before uploading it to the Stockfish web site, I would like to have some independent confirmation that it works. Please download from this URL:

http://www.mediafire.com/?yzjyz3dingu

Before you get too excited, this is still only the old and amateurish Glaurung GUI, with a few minor changes. I have to start working on a new and more polished GUI some day.

The binary probably requires Mac OS 10.6, but might also work in 10.5. It certainly won't work in 10.4. It currently doesn't support PowerPC CPUs (I'll add that later if anyone is still interested), but should work on both 32-bit and 64-bit Intel CPUs. I'd appreciate if those among you who own an Intel Mac running 10.5 or newer could download the GUI and check if it works for you.

There is also one very minor difference in the engine code compared to the stand-alone 1.7.1 engine: If the engine detects 8 CPUs, it will assume that it is running on a quad with hyperthreading, and will use 4 threads by default. This is because quad-core iMacs are probably far, far more common than the outrageously expensive 8-core Mac Pros.

The GUI itself all works under 10.5, but the stockfish binary you bundled only works under 10.6 due to a change in the way the loader works. After replacing that binary with one I compiled myself, everything looks like it's working perfectly. If you want to use a system running 10.6 to compile a stockfish binary that's compatible with 10.5, you just need to add the following flag when compiling (assuming your SDK is in the default location):

Code: Select all

--sysroot=/Developer/SDKs/MacOSX10.5.sdk

Thanks for testing!

I have had some trouble compiling a working executable with MacOSX10.5.sdk before, and was too lazy to try this time. I'll try to get it working (and also to produce a slightly faster binary) before I upload the final version to the Stockfish web site.

Congratulations on a great engine; it's inspiring to see how effective your open approach has been. I've certainly learned a lot from your code, and I'm very happy that such a strong and well-written engine is available for anyone to learn from.

Thanks for the kind words, and for making Daydreamer available to us all as open source. We're on the same team.

schlucke wrote:

Tord Romstad wrote:I have now prepared a GUI release of Stockfish 1.7.1 for Mac OS X. Before uploading it to the Stockfish web site, I would like to have some independent confirmation that it works. Please download from this URL:

http://www.mediafire.com/?yzjyz3dingu

Before you get too excited, this is still only the old and amateurish Glaurung GUI, with a few minor changes. I have to start working on a new and more polished GUI some day.

The binary probably requires Mac OS 10.6, but might also work in 10.5. It certainly won't work in 10.4. It currently doesn't support PowerPC CPUs (I'll add that later if anyone is still interested), but should work on both 32-bit and 64-bit Intel CPUs. I'd appreciate if those among you who own an Intel Mac running 10.5 or newer could download the GUI and check if it works for you.

There is also one very minor difference in the engine code compared to the stand-alone 1.7.1 engine: If the engine detects 8 CPUs, it will assume that it is running on a quad with hyperthreading, and will use 4 threads by default. This is because quad-core iMacs are probably far, far more common than the outrageously expensive 8-core Mac Pros.

Thanks Tord, works fine here on my old MacBook Pro (Core2 Duo) with 10.6.3.

Great, thanks for testing!

Is the sf171 compile on optimized ICC build or GCC?

It's a plain GCC build, without PGO or any other tricks. I'll make some more effort to produce a faster binary before the official release.

BTW: The new Icon is great

This must be the first time someone complements me for my artistic skills.

Actually, I just cribbed two images (an empty chess board and a couple of stockfishes) I found with Google image search, and used GIMP to combine them into an icon.

mcostalba wrote:

IWB wrote: The biggest problem was that Zugzwang detection is weakening the engine, that was something I did not consider - when I read then about the Minimum Split point I was totaly confused ... but all turned out to be ok.

You are right. I will try to explein why zug detection _could_ (because is still not proven 100% but our internal tests say so) weaken the engine.

When SF evaluates a position it stores the position score in a big table in memory called transposition table or hash.

If SF founds again the same position it does not search again through that, but simply uses the already saved position score. This saves a lot of searching effort. It is very common practice and almost all teh engines do the same.

In SF we save the position score _also_ when doing what is techncially called a null move search that is a kind of quick search to see if position deserves to be searched deeper or, being uninteresting, can be skipped.

This null move search is very powerful but has a weak point: it can fail when the position is zugzwang for the side to move. In this case the null search can give a wrong result and reports that the side to move is winning while it is not. Normally is not so dangerous, but if you save the wrong result in the hash table (as we do starting from 1.7), next time you find the same position you think you are still winning yielding to a completely wrongly evaluated position (I am not very precise here because otherwise the things would be a little bit messy, but the concept is this).

So, how zug detection works ?

With zug detection SF simply does _not_ saves in hash table the score for the positions found by null search, in this way you cannot mislead a zug position but at the same time you lose the benefit of having the position score already saved in the hash table and so your search effort is bigger: that's the reason why zug detection could weaken your engine (also in this case the description is not 100% accurate but gives the idea, actually SF saves the same the score but does not use it in certain cases)

I think it will be the opposite. As it was discussed in another thread, saving the results of null searches in the hashtable do not help much, and as a consequence, they actually pollute the hash table. I would not be surprised if SF is ~10 elo points stronger if it does not save in HT the results of null searches.

Miguel

Because real zug position happens very seldom in real games you end up with a bigger searching effort for no real benefit when you enable the zug detection.

I hope it is clear enough.

beachknight wrote:Hi Jim,

Could you please provide another d/l links for SF171?

Best,

Okay, who has been hoarding Stockfishes? Fess up!
You can't eat them you know..

Oops! (509)
This account's public links are generating too much traffic and have been temporarily disabled!

(Code 510, translated message reads: "We took them with us as souvenirs! So long! Thanks for all the fish!")

beachknight wrote:Hi Jim,

Could you please provide another d/l links for SF171?

Best,

Massive download traffic for Stockfish has put an end
to my public Dropbox downloads temporarily.
Mirror links are now available on my homepage (Mediafire)

Jim.