On 11/19/2010 03:03 AM, Joost 't Hart wrote: > On 11/18/2010 07:38 PM, Matthew Twomey wrote: >> I grabbed this from SVN and compiled it. I tried annotating with with >> both Stockfish an Crafty. <zip> >> Overall >> ------- >> In general because the tweaking of the 327 score is so small I'm forced >> to annotate all moves in order to see the improved mate lines (I think >> it's set to a one "centi-pawn" penalty for each additional move when >> comparing mates?). >> >> At my level, I'm really only interested in 1+/- (or greater) score >> changes. What I was hoping for was to annotate a game and have all moves >> that are +/- 1 annotated, but then also all "better" mate lines (such as >> a mate in 3 opportunity, when my move was a mate in 6). > Got your point. You are looking for a situation in which a less optimal > mate variation corresponds to at least 100 cp in normal score delta. > But, given the current way of working, we would need a lot of score > "bandwidth" for mate evaluations alone. > I was not "there" when the value of 327 for "mate" was chosen, so I > have no idea why it is this value. The only thing I can think of is that > +/-32767 (cp) is the maximum value that can be packed in a 16 bit > (signed!) number, so someone took a value close to that limit.
I think I found out. It is crafty (and probably other xboard engines as well) that uses +/- 32767 (indeed :-) ) as maximum score. I was playing a bit with crafty 23.4 (the latest, found out that 23.2 in my distro probably has a bug which causes it to stop when it sees a forced mate) and I happen to have sort-of reinvented the wheel: Crafty subtracts one cp per ply (not per move) if it sees a forced mate. So when it can play a mate in one, the score is 32766. A mate in two is 32764. Funny! I only thought 32750 would be an appropriate number... I tried to check in the xboard standard, but does this hold for any xboard engine and could we use it like that in Scid? Probably not, I feel, which would mean that the xboard annotation story ends here. Which is also the reason why the "Mx" indication in the engine window only shows for UCI engines. If it does hold, I see opportunities to further align UCI/xboard cp and mate evaluations. > All depends on the maximum cp value that a UCI engine can spit > without seeing a mate. That would indicate the bandwidth. > If this value is less than - let's say - 227, we easily would have headroom > for mate-in-100, using 100 cp per move. > When testing with stockfish, I cannot remember the beast scoring more > than somewhere around 120, until it spotted the mate. There could be > another natural limit at 127, but I have no clue about reality... > > On the other hand, I do not know if we can - Scid internally - go to a much > higher integer value for a mate-in-1 as well. Why restrict to 16-bits? So, we could go for any higher value, indeed. > Certainly there are other (and more robust) possible solutions to this > problem that do not base on cp translation at all (although having > a common uci/non-uci "evaluation interface" makes things a lot > simpler indeed). > Maybe we should go that way, yet that is not how things were designed > up to now. I will go for this and leave the cp model alone by simply always adding annotation for faster mating lines. Without nags, that is, and hoping that most xboard engines indeed do see a mate when they report a score above 32700... Cheers, Joost. <zip> ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
