Author: Vincent Diepeveen
Date: 17:48:20 04/27/04
Go up one level in this thread
On April 26, 2004 at 20:07:00, Uri Blass wrote: >On April 26, 2004 at 13:41:53, Vincent Diepeveen wrote: > >>On April 26, 2004 at 12:14:33, José Carlos wrote: >> >>>On April 26, 2004 at 11:57:43, Vincent Diepeveen wrote: >>> >>>>On April 26, 2004 at 11:48:35, José Carlos wrote: >>>> >>>>>On April 26, 2004 at 11:32:26, Tord Romstad wrote: >>>>> >>>>>>On April 26, 2004 at 10:39:42, José Carlos wrote: >>>>>> >>>>>>> An interesting experiment, of course. But I think your conditions are rather >>>>>>>different from 'most' programs. I mean: >>>>>>> - You allow any number of null moves in a row (most programs don't do even >>>>>>>two) >>>>>> >>>>>>This has no importance, I think. My experience is that I almost always get the >>>>>>same score and PV when I enable/disable several null moves in a row, and that >>>>>>the difference in number of moves searched is *very* tiny. >>>>> >>>>> >>>>> You're probably right, as you've tested and I speak from intuition, but at >>>>>first sight, it seems that the fact that you allow several null moves in a row >>>>>will increase your percentage of null-moves-tries/total-nodes-searched, and thus >>>>>that avoiding unnecessary null moves will be a good idea. >>>> >>>>In *all* experiments i did with nullmove and a program not using *any* forward >>>>pruning other than nullmove, the best thing was to *always* nullmove. >>> >>> >>> Yes, that's what other programmers also said (including me) in the thread we >>>had last week. That's pretty intuitive. With not any other forward pruning (or >>>very little) but null move, the cost of not trying a null move that would have >>>produced a cutoff it terrible compared to the benefit of saving an useless null >>>move try. So avoid null move, in this case, must be only in a very few cases >>>where you're 99.99% certain you'll fail low... if any. >> >>99.99% means 1 in 10k nodes. > >No > >You can be 99.99% sure about fail low more often than 1 in 10k nodes. Not really, crafty has 5% fliprate. So it is just 95% sure always. Note i did experiments with diep. Fliprate is <= 1% there (also near leafs) so i had always at least >= 99% sureness. >> >>So doing nullmove always is cheaper, because in a lot of cases >>transpositiontable is doing its good job and in other cases you search more than >>10k nodes which you avoid searching now. >> >>> Gothmog is very different from that 'paradigm' (he does a lot of forward >>>prunning and applies many ideas he has commented here), hence it works pretty >>>well for him. >> >>I get impression evaluation function plays a major role in when something is >>useful or when it isn't. >> >>Checks in qsearch is also a typical example of this. >> >>> >>>>Double nullmove i invented to proof nullmove gives the same results like a >>>>normal fullwidth search for depth n which i may pick, and i use it as it finds >>>>zugzwangs and i am sure that is very helpful, because the weakest chain counts. >>>> >>>>So double nullmove always completely outgunned doing a single nullmove then >>>>disallowing a nullmove and then allowing the next one. >>> >>> I tried double null move some time ago, and it didn't work for me. Probably I >>>did something wrong, but I recall an old post (see the archives) from C. Theron >>>where he gave some points why double null move should not work. I, myself, >>>didn't invest too much time though as I had much weaker points to fix in my >>>program before. >> >>Christophe didn't post it doesn't work AFAIK. >> >>Further i must remind you that majority of commercial programmers posting here >>is not busy letting you know what works for them or doesn't work for them. >> >>To quote Johan: "don't inform the amateurs". > >What reason do you have to tell other what works for you and what does not work >for you? > >You do not plan to inform the amateurs about better code for tablebases than the >nalimov tablebases so I do not see you as a person who try to help the amateurs. > >> >>I remember that Christophe also posted that evaluation function is not so >>important. >> >>His latest postings here made more sense however than the crap posted before >>that. > >I understand that you claim that basically Christophe's claim that most of the >improvement in tiger came from better search and not from better evaluation was >disinformation. >I see no reason that we should believe that the things that you post are not >disinformation. > >Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.