Author: leonid
Date: 12:13:09 10/17/99
Go up one level in this thread
On October 17, 1999 at 14:17:18, Jeremiah Penery wrote: >On October 17, 1999 at 14:07:55, leonid wrote: > >>On October 17, 1999 at 11:52:28, Jeremiah Penery wrote: >> >>>On October 17, 1999 at 08:07:01, leonid wrote: >>> >>>>On October 16, 1999 at 19:26:57, Jeremiah Penery wrote: >>>> >>>>>On October 16, 1999 at 17:51:46, leonid wrote: >>>>> >>>>>>To put in the chain of moves first the moves that give the check is simple - >>>>>>those moves can lead to the mate. Mate stop all the thinking, once the highest >>>>>>possible value is achieved. >>>>> >>>>> >>>>>It is true that these moves can lead to mate, but not very often. In fact, most >>>>>of these moves will be useless. Take this example: 1. e4 e5 2. Bc4 Nf6, then >>>>>the move Bxf7 is a check, but it is completely useless. I suspect this will be >>>>>the case for most checking moves. >>>>>My guess is that sorting moves first because they give check probably won't give >>>>>good results compared to other orderings. >>>>> >>>>>> Looking through the "tool" I found that the number >>>>>>of moves that lead to check is very small. This is the next reason for leaving >>>>>>those moves at the head of the chain. >>>>> >>>>> >>>>>This is true, but if the first move is very bad, you still have to search it >>>>>fully. Like in my Bxf7 example above, that is a bad checking move, but you >>>>>would still have to search it fully before searching other moves. This will be >>>>>bad for the branching factor in your program. >>>>> >>>>>>I looked into your description of the move ordering and I hope that I understood >>>>>>correctly everything that you have said. It is probable that our move ordering >>>>>>is very close but we explain it in a different fashion. >>>>>> >>>>>>Languages that we use are not the same. Mine is Assembler. Until now wrote >>>>>>everything for DOS but prepare to rewrite everything for Windows. And for what >>>>>>system you write? Or probably Java is already perfect for every system? >>>>> >>>>> >>>>>It's quite difficult to write a program in assembler, as it makes it difficult >>>>>to easily modify. I wish you luck. :) >>>>> >>>>>Jeremiah >>>> >>>> >>>>When I responded to your question at 1 o'clock in the morning (after working 5 >>>>hours by phone) I probably was too tired to see one reason. I speek about the >>>>usefulness to have the moves that make check, to the ennemy king, on the head of >>>>the list. Statistucally it is good for sure, I did the counting, but from logic >>>>point of view it is mainly because checking moves limites greatly number of >>>>moves that opposit side can execute. This probably is the reason for speeding of >>>>the logic. >>>> >>>>When during the generation of the moves for given ply, the indication of the >>>>moves that will check is found, this can be done in pretty quick way. More you >>>>have the nodes in the plys, more efficent legality and the checking aspect is >>>>accomplished. And for the same funny reason (just saying this because I reached >>>>this place) worst is you logic (more nodes you are forced to see in each ply) >>>>more your game will shine with its positions per second ratio. >>>> >>>>Leonid. >>> >>> >>>The idea with move ordering is that you want to be searching the "best" move >>>first. A checking move can be very good, but _most of the time_ it will not be >>>the best move. If you search a checking move, you must take the time to do the >>>full search on it. If it is a bad move, you will have to find a better move, >>>and then do another full search, which can end up taking twice as long. With >>>better move ordering, you can be searching the better move first, and so you >>>will not have to re-search on as many positions, because you can get faster >>>cutoffs. This will save time and lower the effective Branching Factor. >>>It is possible that searching checking moves first does help you - I am >>>interested to see results. :) >>> >>>Jeremiah >> >>You know, maybe what you have said have some sense. I must simply try this once >>again. Everything is possible because even today I found that probably my >>yesterday moveordering was not good. Have impression that now there are more >>simple way. Before I used the chain of the last best 8 moves for given ply, and >>now only two best moves from the past. One of those moves is neutral and other >>that give material advantage. Alignment of the moves before using the best >>recent moves in consideration is the same: moves that make check, moves that >>give material advantage, neutral moves. When will finish with this, will try >>once again what you are suggesting. Will generate the moves for the ply that >>don't produce the mvoes with check at the head of the moves chain. > > >If a checking move is good, it's fine to put it at the head of the move >ordering. The only problem is if you put them _all_ there, because most of them >will probably be bad. > >I don't know how you can determine whether the move is good or not before >searching, though. :/ > > >> Only by >>trying the speed for the same position by different logic real efficiency of the >>logic could become evident. > > >Yes. :) > > >>One small reason why I can't say for sure now if your idea is right. I still >>have nothing in my logic that is memory consuming, like hash table for instance. >>This I will touch only when I will find that my basic logic is quick enough. > >I'm glad you are skeptical about my ideas. :) There's always a chance that I'm >wrong, and for your program, your ideas might be better. > >Jeremiah But what is your way to align the moves in the ply? It is just like mine with exception for its first part? 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.