Author: Uri Blass
Date: 13:06:56 10/03/03
Go up one level in this thread
On October 03, 2003 at 15:57:03, Uri Blass wrote: >On October 03, 2003 at 15:36:22, Mridul Muralidharan wrote: > >> >>You misinterpreted me. >> >>On October 03, 2003 at 14:51:24, Uri Blass wrote: >> >>>On October 03, 2003 at 13:38:54, Mridul Muralidharan wrote: >>> >>>>Hi, >>>> >>>> I was a bit taken aback by these declarations : >>>> >>>>On October 03, 2003 at 12:47:23, Uri Blass wrote: >>>>>I prefer even not to care about using hash tables for pruning because my >>>>>experience told me that I cannot get significant gain there easily >>>> >>>>Hash table not giving you pruning ? I suspect a bug in your hashkey - >>>>nothingelse. >>>>Or maybe it is the easily that is operative word ? >>>>I think there are a lot of open source programs that you can refer to and >>>>correct your bugs with - crafty , GNUChess , etc , etc. >>>>Might help to get this right. >>> >>>I do not like to copy from other sources. >>>I found that instability helped me to do my program significantly better. >>> >>>If I delete it in order to be able to copy from other programs then I may need >>>to start by doing it significantly weaker. >>> >> >>I did not mean - "copy" here. >>Rome was not built in a day. What I meant is : >>Look at their implementation - check yours. Find any obvious bugs. >>I seriously suspect that there are - since hashtables not only help in pruning , >>but massively help in move ordering. > >I already use them for that purpose. >I did not say that hash tables are not used. > > > >>If you can afford to make these statements - then your impl is horribly full of >>bugs. >> >>As far as "instability helping" - I'm really not sure what you mean by this. As >>far as I know - everyone , including me , tries to reduce instability so that >>search is more stable requiring minimal search tree. >>Wild extensions , unstable pruning , etc may help you in solving test suites >>better and faster - but in real world games , it will suck badly. > >I test also in games. >> >> >>>> >>>> >>>>>(I have a lot >>>>>of stuff that means that pruning or extension is not defined only by the >>>>>position). >>>> >>>>Where ever possible , I try to make the search behaviour as relevent to the >>>>current position as possible and not rely on past search. >>>>Why do you want to do the opposite ? >>> >>>because the opposite gives me some advantages. >> >>test , test , test - dont assume. >>like my collegue says : When you AssUMe , you make an Ass of U and Me ;) > >I test. > >> >>>Movei has its chances against every program inspite of having bad order of moves >>>and bad extensions and bad pruning. >>> >> >>acceptance is the first step to improvement ! >> >>>I believe that I can get above Crafty level if I improve order of move >>>extensions,pruning and evaluation. >>> >>>Movei already has its chances against Crafty but today crafty is significantly >>>better. >>> >>>There is a lot to improve and the main problem is programming. >>> >>>Uri >> >> >>AFAIK movei is not smp - so no point in saying search here :) >>SO , other than move ordering , eval and pruning : what else is left ? interface >>code ? ;) > >code. > >I do not plan to use smp and I believe that the things that I mentioned can give >a lot. > >>anyone can get to crafty level or higher - IF you are willing to put in the >>effort and scientifically research. >>All the best - wishing to see a better Movei and a more scientific Uri :) > >You misinterpt me. >I did not decide that something is better based only on test positions. > >Uri Note also that I looked at the source code of Crafty and learned somethings from it and I also looked at the source of tscp and understood most of it before writing movei. 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.