Tuning again

[bob]

You can of course simply count nodes in such a way that your program does not speed up. How you count nodes is pretty much a matter of taste anyway. Some people count MakeMoves, other count MoveGens, still other count Evals. Would you count nodes that are hash pruned or not, etc.

Problem is, my move generator speeds up as pieces are removed. Ditto for eval. I am not sure how I would factor that out. Other things also speed up as the game progresses, such as SEE. I've not really tried to enumerate the places where I gain (or possibly lose) speed. But they are all over. Search overhead goes up as pieces come off, for one...

[Rebel]

Hi Vincent,

Nice to hear from you again.

Hi Ed,

In itself running fixed depth matches is not a bad idea. However it tunes a lot better if you get through tactical barrier. That barrier is far above 8 ply.

Of course you are right and in an ideal world I would use 16 plies. But 8 ply plus 10,000+ games is good enough nevertheless since the volume weeds out the randomness.

[Dave_N]

Code: Select all

{  
   { 
       { 
           {
           }
       }
   }
}

Things like that drives me crazy

Mee too The problem here is the excessive indentation level more than the brackets in itself.

From http://kerneltrap.org/files/Jeremy/CodingStyle.txt:

"Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

I prefer the phrase "nevermind the brackets, I'm late for breakfast".
I think the asm-style C is very nice to look at, reminds me of san kit.

[diep]

Hi Vincent,

Nice to hear from you again.

Hi Ed,

In itself running fixed depth matches is not a bad idea. However it tunes a lot better if you get through tactical barrier. That barrier is far above 8 ply.

Of course you are right and in an ideal world I would use 16 plies. But 8 ply plus 10,000+ games is good enough nevertheless since the volume weeds out the randomness.

8 ply is too little. The randomness of the shallow search not getting through tactical barrier means you suddenly need 100k games instead of 10k with a bit deeper search depth, as randomness always converges towards equality (50% score). So randomness you can never filter out very well as it has the tendency to converge towards that 50% score. Avoiding randomness in the first place should be your main focus.

Even then it will never tune accurately of course, they use better ways of tuning than this nonsense testing. For this if i may refer to that Stockfish team first says they test 1000 games at 1 0 level, now statement is they test at 5 seconds a game + 0.1 , whereas they're higher rated than crafty and crafty already had to move up in time control, meanwhile crafty plays 40k games, not 1000. Then even despite being retired i assume you smell the contradiction of the random statements the dudes do here.