Author: rasjid chan
Date: 12:23:13 08/27/05
Go up one level in this thread
On August 27, 2005 at 10:40:12, Tord Romstad wrote: >On August 27, 2005 at 04:04:40, Daniel Shawul wrote: > >>On August 27, 2005 at 01:42:32, rasjid chan wrote: >> >>> if (white) >>> score = pst_pawn[sq88To64(sq)]; >>> else >>> score = pst_pawn[flip[sq88To64(sq)]]; >>> >>> I can't get a macro substitution for flip[64] - excuse my IQ. >> >> There is. You just have to get the rank and file of the square and >>build the necessary fliped square from this. But this is just so slow. > >What's wrong with a simple "#define FLIP64(x) ((x) ^ 56)" ? Looks >at least as fast as a table lookup to me, but I'm no expert. > >>>3) I have a max rank/file distance macro here, the best I can manage is:- >>> >>> #define max_rf_distance(x, y) max((x)-((y)&0xf0)&128? (y)-((x)&0xf0)>>4\ >>> : (x)-((y)&0xf0) >>4, (x)-(y)&8? (y)-(x)&7:(x)-(y)&7) >>> >>> Is there a better trick for this? >>> >> No other trick. You can try a distacne[64][64] array, which might be slower >>on some systems. > >Rasjid said he was using a 0x88 board representation; I would therefore >recommend that he tries a distance[256] array. Daniel, It is precalculated for 0x88 dist[128 + sq1 - sq2], [64][64] don't look good. > >>>4) retrieving the PV. >>> This was discussed over at the winboard forum but I am still not too clear. >>> We have :- >>> a) the pv[ply][ply] method. But hash probe returns on exact usually make >>> the PV short. Is this superflous when there is hashing? >> You can have longer pvs if you don't use hash tables at PV nodes, if you >>dont use null move at pv nodes, if you don't use other prunings at pv nodes. >>But are you ready to pay its cost? > >Hash table cutoffs can certainly cause the PV to be incomplete, but I don't >see how null move pruning or the other most common pruning techniques >can limit the PV length. I never allow hash cutoffs at PV nodes. This has >the nice consequence that the PV is never truncated, and the static eval of >the position at the end of the PV always equals the return value of the search. >The cost is almost zero. I first read about this much earlier and have a vague idea when Fabien mentioned it. I recently tested and it seems withot drawback. But then it was with plain alphabeta, not PVS. At pv nodes with exact,I don't cutoff but continue the search with alpha-1,alpha+1 just to further backup a complete pv - seems ok. I further added minor tweaks(that may be incorrect).I disable timeout() when an exact score is found, ie an improvement over the current root score that may end as the new pv. This may allow last minute improvement to reach the root and there is no time falure, probably like good time management. Also I don't allow timeout() until root returns from searching the second move. Searching the first move without having anything to compare with seems not right. Again seems ok as I don't experience any time failure. > >Tord
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.