Author: Tony Werten
Date: 04:45:06 10/21/01
Go up one level in this thread
On October 20, 2001 at 18:10:48, Antonio Dieguez wrote: >On October 20, 2001 at 16:17:09, Tony Werten wrote: > >>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 guess you mean "I don't matter explaining to interested people" :) Actually I forgot to type in "mind" > > >>>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. > >ok... > >>>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. > >the exponential ones finished? I meant the search and killers and prunning and >stuff, how can you finish that?? since when Xinix outsearch Fritz? :) I think >you mean when you just can't advance via this way then try with the other, and >change track next time when you have the same problem again. When you start you can win a lot with killers and pruning and stuff but at a certain point the biggest winners are finished and you have to start with the then biggest winners wich are smaller than the first ones. A good evaluation can give a big win, but it's a lot more difficult and takes very very much time. > >>>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 ) > >may be. I only tried a small set of positions(just 5!) and set it to search to >depth 9 and taken the total time used. Next time I will more and more variated >positions. I guess this is the way to test this? is a fact that hashtable data >affects search in the next move too in a game but the normal and the eval >hashtable as well so I hope this cheap way is enough... Until a certain level, using testpositions is good enough but you need more than 5. BT2630 is good to start with but you need more than 9 ply for most searches. Even then you still have to use common sense. If you know you put in something good it can still decrease the testsuite result. In my program I found a bug that scored a passed pawn on the file it was on instead of the rank. I changed it and the testsuite result went down with 50 points :( Another problem with testsuites is what to do with the results. Suppose you change something and 4 positions gain 5 points and 1 looses 30. Total result is minus 10. Keep the change in or not ? > >Thanks for all and good bye.
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.