Author: Uri Blass
Date: 02:54:28 12/20/02
Go up one level in this thread
On December 20, 2002 at 05:31:38, Andreas Herrmann wrote: >On December 20, 2002 at 01:34:17, Uri Blass wrote: > >>On December 20, 2002 at 01:31:08, Uri Blass wrote: >> >>>On December 19, 2002 at 19:53:46, Andreas Herrmann wrote: >>> >>>>On December 19, 2002 at 19:21:04, Uri Blass wrote: >>>> >>>>>On December 19, 2002 at 18:49:56, Dann Corbit wrote: >>>>> >>>>>>On December 19, 2002 at 18:47:22, Joshua Haglund wrote: >>>>>> >>>>>>>Anyone know of a good site(s) for the programming of a (legal) move generator? >>>>>> >>>>>>You'll find a lot more help looking for a pseudo-legal move generator. I don't >>>>>>think anyone makes a strictly legal move generator (maybe Uri does...) >>>>> >>>>>I did it and chest also did it and I remember that other programmers also did >>>>>it(Miguel started with legal move generator and I remember that peter makanzi >>>>>also does it(or at least did it in the past)). >>>>> >>>>>pseudo legal move generator is the easy way but I do not think that it is better >>>>>and the fact that chest is the best mate solver suggest that legal move >>>>>generator may be better. >>>>> >>>>>Uri >>>> >>>>Hi Uri, >>>> >>>>but a pseudo legal move generator is faster. You have to check if the king is in >>>>check only if you must evaluate a position. >>>>What is the advantage of a slower legal move generator? >>>> >>>>Andreas >>> >>>The advantage is that I get more knowledge that can be used for better order of >>>moves or extension rules or pruning rules or evaluation. >>> >>>one example is that it is easy for me to check if the king is in check because I >>>update a varaible to know it after every move. >>>Another example is that it is easy for me to check if a piece is pinned to the >>>king because I have an array that tell me for every square if it is pinned. >>> >>>one of the changes that I added to movei to do it faster is adding an array >>>pinnumber[ply] and now I can check if there are pieces that are pinned very >>>fast. >>> >>>I still cannot detect fast the value of the pieces that are pinned and their >>>square so it may be better to change the array again and I think that it is >>>possible that I can use some arrays for information about pins to give all the >>>information when in 99% of the cases only one of them is going to be used. >>> >>>If people have good ideas how to store that information then it may be >>>productive(today I store information only about pinned pieces of the side to >>>move and it also may be faster to store information about pins of both side). >>> >>>Uri >> >>To be more correct today I have an array for the 64 squares but I know that the >>only squares tht I use and can trust are squares of the side to move. >> >>The information that I have in the array today is also the direction of the pin >>in numbers 0-3(-1 is for no pin,0 for pin in the same file,1 for pin in the same >>rank,2 and 3 for pins in diagnols) >> >>Uri > >Hi Uri, > >sounds interresting, but doesn't cost that too much time to update all these >things during move generation. > >Andreas I work months on improving the speed of the move generator so movei is not so slow. In my first implementation it was really slow because I generated the attack tables from scratch so movei could do less than 10Knodes per seconds when it calculated perft and it was really too slow but today it is not slow. First public movei had similiar speed to tscp and next movei is going to have also similiar speed. I can live with the speed because part of the commercial programslike Hiarcs seem to be not faster. there are some speed improvement in the move generator of latest movei but calculating checks in the first plies of the qsearch is not done in the most efficient way and it takes time. latest movei is not faster than public movei in nodes per second and even slightly slower mainly because of checks in the qsearch(in order to do checks in the qsearch it calculates for every legal move if it is check and it is not the most efficient way to do it). movei is using only C(no assembler tricks) but there are clearly things that need to be done not about assembler to do it faster[I believe that a speed improvement of at least 50% in nodes per second can be done by hasing the qsearch and using hash tables more efficiently(to save generating moves and save calculating possible checks)] 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.