Author: Tony Werten
Date: 13:17:09 10/20/01
Go up one level in this thread
On October 20, 2001 at 10:14:24, Antonio Dieguez wrote: >On October 20, 2001 at 06:04:54, Tony Werten wrote: > >>On October 19, 2001 at 18:41:10, Antonio Dieguez wrote: >> >>>On October 19, 2001 at 17:05:37, Tony Werten wrote: >>> >>>>On October 19, 2001 at 13:21:55, Christophe Theron wrote: >>>> >>>>>On October 19, 2001 at 03:02:28, José Carlos wrote: >>>>> >>>>>> Ok. It seems we agree in the background, but disagree in the surface. Software >>>>>>is much better now, true. Hardware has helped software developement, true. The >>>>>>point we disagree in can (I think) be said in a line: >>>>>> I believe that, if Frans would have back then the kind of hardware we have >>>>>>now, Fritz 3 would be much stronger, much closer to Fritz 7. And for the same >>>>>>reason, if we had now exactly the same machines as at that time, we couldn't >>>>>>have done many of the things we do now. That's all. >>>>> >>>>> >>>>> >>>>>Many improvements in software do not involve having a better hardware, they just >>>>>involve having time to work on the program, having ideas and having time to >>>>>implement them. >>>>> >>>>>It just takes time to imagine the new search algorithms and to work out all the >>>>>cases where your evaluation fails. For example it takes time to evaluate better >>>>>the passed pawns, and I can tell you it does not involve having a better >>>>>computer... >>>>> >>>>>Fritz3 is pretty poor at evaluating passed pawns. Frans did not need a better >>>>>computer to solve this, he just needed more time to work on the program, and >>>>>that's why Fritz4 was better in this regard, then Fritz5 was better and so on. >>>> >>>>I agree about needing time, but I don't think this is a good example. A couple >>>>of years ago, memory was quite limited, so no place for pawnhashtables. Without >>>>hashtables, evaluating pawnstructures is quite a hard job so it was kept simple. >>>> >>>>Passed pawns ( with other pawn stuff) is IMO an example of where hardware >>>>improvements improved the precision of the evaluation, more than just speed it >>>>up. >>> >>>Hi. >>> >>>How you do it? >>> >>>I don't have implemented yet pawn hashtables(in part because I don't believe >>>they would help me more than a bit, if), but how do you use it to handle passed >>>pawns? I suppose you store only the score? >> >>No, I just use it to identify some characteristics. >> >>>if so, how you do it to not calculate >>>passed pawns anyway in eval to see if it is obstructed or supported? >> >>You still have to do some work, but you can reduce it. >> >>My pawnhashtable consist of a lot of bytes where a bit is set if there is a >>passedpawn, doublepawn, backwardspawn or anypawn on that file. (so 4 bytes times >>2 colors) >> >>This is quite expensive but on average I can take it out of the hashtable 99.9% >>of the time. So basicly I can do whatever I want in my pawnstructure code. >> >>Isolated pawns I dont store because they can be calculated by: >>onepawn[player] and not((onepawn[player] shl 1) or (onepawn[player] shr 1)) >> >>Further I hash the kingsafety left and rigth for both sides,( absence of pawns) >>and a score if the pawn is defended by other pawn etc. >> >>In my pawn evaluation I just and the line of the pawn with the byte to see what >>kind of pawn it is, then I look for the other stuff. >>So fe: >>if passedpawnbyte[color] and (1 shl (pawnfile))<>0 then //check if there is a >>piece in front of this pawn etc. >> >>If kingfile>E1 then safety[player]:=kingsafetyright[player]*weightedmateral >>if kingfile<D1 then .. >>else // king still in the middle >> if onepawn[player] and (1 shl kingfile)=0 then //your on a semiopen line >> if onepawn[oppo] and (1 shl kingfile)=0 then //even worse it's open >>etc >> >> >>>by the way >>>also the material on the board would be hashed?... >> >>No, only pawns. Your pawn hitrate would go down too much if you include it. >> >>Material is a different hashtable in my program(I have 5 in total) This has the >>funny sideeffect that my speed on ply 10 is about 5 times that of ply 2-3 ( >>still filling the tables) on testpositions. In game the difference is smaller >>but still noticable. > >Hi Tony! > >Not that I understand all what you wrote, but thanks for taking the time to >explain! Just ask. I'm not a teacher but I don't explaining to interested people. >I have thunk about implementing the pawn hashtable but thought that storing it >only a part of it and also tweaking it later would make my code more messier and >not faster. In my program, filling this table is a different procedure and can be used as a black box. >And always prefer to think more time about the eval itself, and also >exponential improvements, not linear anyway. Me too, but at a certain point the exponential ones are finished and you should go on with the linear ones. >By the way, 5 hashtables... wow :) I have only 2, the eval and the normal, by >the way I have 59% of ram for the eval one, I know that other programs destinate >much less for that, well, I hope enough ram is used. Way too much. ( My experience, not the absolute truth ) Take some tests. One counter for calls to materialhashtable, one for getting a hit. Materialhashtable scored very bad in my program. I needed 64 Mb to get a decent hitrate ( only 50%, and you can't even trust the result) . You can use those for more usefull things. ( king distance to pawns (very usefull for endgames), in memory endgame tablebases etc.) cheers, Tony > >Be well...
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.