Author: Vincent Diepeveen
Date: 14:31:18 08/30/03
Go up one level in this thread
Steven with all respect, but shredder your high level design stuff. The reason i will give you with a number of reasons. First one is that the low level determination of a pattern X is the most important thing. So talking at high level when the low level misses crucial definitions is only exponentially giving a program wrong decision taking. Those 'unrelevant' details are determining how good a program is. second one is that we all know how good you are in datastructures from the past. You are so good in them, that you create classes which are needed to fix the fact that a low level class was wrongly defined, then another 5 classes are needed to fix that. The result is that no one is capable of understanding a iota of your code. However we know from textbooks that the best way of design is a top down design. The way you construct your classes is however bottom up. We can clearly see from code that high level classes are only there to fix 'trivial functionality' that low level classes are intended to do. third argument is that you will never understand computerchess being busy in this way. Where my opinion is that you try to do some effort and share that with others, others judge that directly as someone doing only effort for himself to look better. fourth argument is that if there is need for any high level class you are designing currently. If there is a need for anything then that need is for parallel search. fifth argument is that without knowing the lower classes implementation of the datastructure persons will not be capable of making complex evaluation knowledge. Now perhaps that's not relevant to you, but it is relevant if they ever want to join a world championship and not end last or one last. If you would make a parallel search 'class', like Cilk, but then a better implementation, the community would be able to benefit from your work. Right now they only laugh for it, which IMHO is not a good idea, and i'm not doing it at all. I'm just giving this signal publicly hoping that you realize how the commercial programmers are looking towards you. So i hope you don't see all what i wrote here as my personal opinion, there is many programmers who simply never write in this forum, who say way ruder things during tournaments or online chats about guys like you, which they never dare to write down. No matter how rude some people judge some postings i do here it does not even closely approach the way some of the stronger chessprogrammers speak about regular contributors to this forum. Because you are a very serious person, i definitely write it down here. The only real need for many amateur programmers currently is a parallel search implementation. There is a need for a high level class there. Something that is easily usable in chess programs without forcing them to do search in a certain way. Like many commercial engines i'm not having a recursive search for example. That's problem 1 you have to fix. Making a non-recursive parallellism. You'll soon find out why when you search parallel. Hyatt has even written it down on paper in ICGA journal and many times in forums. I could give a number of reasons why there is a big need for a parallel implementation of the search. However they are so trivial that i will not do it. All i want to refer to is that cilkchess was a very good try, but regrettably failed because it was written by some professors who know shit from search and how to PROGRAM for a parallel environment. All those implementations like theirs and zugzwang were latency dependant. Schaeffer did a better try with Aphid but his algorithm i can confirm to scale very badly above 16 processors. He noted that himself too. Also his speedup numbers aren't true, like he already noted, when you use stuff like nullmove and good working hashtables. In fact it gives a poor speedup at 2 cpu's already. There is a need for a public implementation of YBW designed in a top down way. My code won't be released. On August 30, 2003 at 15:32:21, Steven Edwards wrote: >On August 30, 2003 at 14:37:44, Tord Romstad wrote: > >>My program has reached the stage where it is so complicated and ugly that I >>no longer understand clearly how it works (it's rather miraculous that it >>works at all), and there are many parts of the code which I am afraid of >>touching because I am sure I will break something. Besides, the program >>is horribly slow, searching only about 120 kN/s on a PIV 2.4 GHz. > >Comparisons of node frequency are only valid between programs that process >essentially the same information at each node. So 120 KHz cauld be sluggishly >slow or blindingly fast; it all depends. > >In the Old Days, the first Tech program was, by design, the fastest program in >terms of node frequency. But it was not a top scorer because relatively slower >programs apparently processed more information per node and used it more >effectively. > >>1. One of the things I dislike about bitboards (at least the modern >>approach with rotated bitboards) is that even very simple operations >>like generating moves seem to require either using huge lookup tables >>(like in Crafty without -DCOMPACT_ATTACKS) or writing some extremely >>complicated and unreadable code (like Crafty _with_ -DCOMPACT_ATTACKS). >>Is there a way to use rotated bitboards without having big tables, >>and still keeping the code short, clean and readable? > >I have some mixed feelings about rotated bitboards, so they are not currently >used in the CT toolkit. However, the use of rotated bitboards is a low level >design feature and a decision on using them is one you can defer until you can >get the rest of the bitboard operations working. > >Indeed, the higher level tasks of a chess program should be blissfully ignorant >of the low level details of data representation. In C++, the use of either >standard or custom templates for container and iterator classes can completely >isolate the detials of storage and access of moves, boards, etc. > >>2. Another problem with bitboards is that there is no obvious way to >>compute "weighted mobility". While it is trivial to compute the number >>of pseudo-legal moves for a piece with bitboards, this number is usually >>not very interesting (at least not in my program). In most cases, some >>squares are much more valuable to attack than others. Given a 64-byte >>array of weights, and a bitboard of squares attacked by a piece, is there >>a fast way to compute the "dot product"? I have browsed the archive >>and noticed that this question has been discussed numerous times before, >>but I have never seen a good answer (Bob has explained a lot of times >>how to do this on a Cray, which is not very useful to me). > >If both the bitboard and the array values change both much and often, there's >not a lot that can be done. But if, say, the weight array values are fairly >constant, it would be possible to generate look-up tables that are indexed a >byte or word at a time using chunks of the bitboard value. There are other >approaches as well. > >>3. I also dislike the fact that bitboards are much too big to be used >>as indexes to lookup tables, and that extracting information from them >>is often difficult to do without looping through all the 1 bits. It is >>easy to compute a bitboard of all pieces which attack a given square, >>but in my evaluation I want to extract information about the number and >>types of attackers in a small and compact bitfield (which can be used >>as an index to a lookup table), while throwing away information about >>the locations of all the attackers. How do I achieve this with bitboards? > >Well, how would you do this *without* bitboards? Write up some code for that, >and then see where parallelization via bitboards can speed up things.
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.