Author: Jeremiah Penery
Date: 15:10:19 10/27/99
Go up one level in this thread
On October 22, 1999 at 19:19:26, leonid wrote: >On October 22, 1999 at 13:03:19, Jeremiah Penery wrote: > >>On October 21, 1999 at 23:56:48, leonid wrote: >> >>>Please, say your suggestion! You have your basic logic and want to find its raw >>>speed. How you will proceed? >>> >>>The speed of your logic when its go to solve the mate positions you already >>>found. You only want to know how quickly your logic respond in all other >>>situations. >> > > >>What exactly do you mean by 'raw speed'? Are you looking for > >Speed for finding the move in the position when your logic look every >possibility that exist in a give number of plys. Logic do search through the >"brute force" but not use any "extensions". Extensions must be not used because >they confuse everything, since in every next game it is probably something else. But some extensions can be important to the search. For example, if you are in check, how will you know if you can get out of check without extending? Or if you see that you will be mated, will you extend to find a way to prevent this? Going overboard on extensions can severely cripple your search, but some extensions can help a lot. If your program can play well without them, that's just as well. :) I'm not trying to tell you that you must use them - they can either help or hurt, depending on how you use them. >>A) Nodes/Second (NPS) > >It is useful to see but not give the final truth. Sometime logic that have poor >"branching factor" will give magnificent Nodes/Second. > >>B) the time it takes to get to depth 'x' > >Exactly. ARGH! I wrote a nice paragraph here, and then the computer decided to erase it. Now I must try to reconstruct it... Speed is important, but not if you have to sacrifice quality. If you can make your program reach depth 100 in 1 second, but it still plays badly, then what have you accomplished? However, if it can only reach depth 5 after many minutes, but it plays _really well_, you have accomplished much more. If you can find a way to make your program faster, but still have it play as well, that's wonderful. I think if you're worried about what others are doing, you may not be able to be as creative in solving the perceived problems. I guess the point is that speed doesn't have to be important. If your program plays well, that is much more important than speed. If you absolutely can't find a way to make your program faster, then try to find a way to make it play better. If you can make it faster somehow, more power to you. :) >>C) the time it takes to solve test positions? > >To be able to campare the time that it took to find the move for the same >position on different logics. I don't speak about solving the mate positions. >For this I have special logic and its speed was found. Logic for solving the >mate don't say me how speedy the positional logic is. Both use the same move >generator but are different. > > >>If (A), I would say don't worry about it. Among the commercial programs, some >>have about 40k and some have 400k. > >Agree! > >>(B) is directly related to the Effective Branching Factor. A lower branching >>factor will give you better times. However, it is also related to the number of >>extensions done. Doing many extensions will lower the 'depth', but can still >>see the same information. > > >Here I am not sure that something useful could be found when you have as the >logic to compare something that have inside the "extensions". This is because of >existence of "extensions" that I could never find the way to fugure out the raw >speed of my logic. Among the commercial programs, time to reach depth 'x' is as different as NPS. Hiarcs may take 10x as long to reach depth 'x' as Fritz does...Does this make Fritz play better? >>(C) may be interesting - test positions are nice, but the program's strength in >>real games is more important. > >Before you go to do your real game, you must have your basic logic that work at >the highest speed possible. When this is done, second part is still to be >accomplished but this sound as only the final effort. > > > >>Hope this helps a little, even though it doesn't really give an answer. :) >> >>Jeremiah > >Thanks you very much for trying to help me! Maybe my last explanation will help >you to see if you can suggest me some practical solution. Sometime solution is >very simple but only after you already found them. > >Leonid.
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.