Author: Uri Blass
Date: 04:39:50 07/03/03
Go up one level in this thread
On July 03, 2003 at 05:23:59, Peter McKenzie wrote: > >Sounds great in theory, but in practice it seems unlikely to succeed. What >you're basically saying is that one person (the designer) will come up with all >the clever ideas and the other person (the implementer) will translate it into >code. Possible problems with this approach: > >1) the designer will often overlook important details, and in chess programming >details are everything. When the implementer is told 'go implement A,B,C' he >will go and try to do it and discover issues X,Y,Z. At this point he can go >back to the designer and discuss the issues, the designer will come up with a >bunch of extra suggestions, and off the implementer goes again. This cycle can >go through quite a few iterations and will be quite time consuming. If the implementer is good then even some iterations may take less time than the situation when the designer tries to do all by himself and if the designer is good then cases when he overlook important details in the design are not going to be very common. > >At some point the implementer will have to just cut the code and be done with >it. But if he does so too 'early' in the cycle he'll end up making his own >design decisions, so the designer will start to lose touch with what is actually >going on in the program. If the implementer cuts the code too 'late' in the >cycle then he floods the designer with way too much detail slowing down the >whole process so that it would have been faster for the designer to write the >code himself. > >2) the implementer gets sick of doing all the donkey work! If the implementer >is a highly skilled programmer (and if he isn't it defeats the purpose somewhat) >then odds are they have quite a few of their own ideas they'd like to try. > >3) the designer might not have a good enough grasp of what is feasable and what >is not. If they really understand things that well, then they'd probably be >better off just writing the code themselves I think that often problem of bugs is not a problem of not having a good grasp what is feasable. From my experience the bugs that I had are usually not a problem of not understanding what is feasable. for example I have 2 varaibles in my program s and sq when s means the side to move and sq means square in the board. One of my bugs was because I wrote at some point s instead of sq and this kind of bug may not discovered immediately if the relevant line is not called often. The advantages of having a good implementor in a team: 1)You do not have to debug your program often. The implementor can add some hundreds of lines without running your program with probability of more than 90% that you have no logical bugs when the best strategy for a bad implementor is to test after every small change(otherwise it is going to be hard to find where are the bugs and you can be almost sure that there are going to be more than one bug). 2)You can have bigger confidence that you have no bugs so if some idea that you try does not work in games then you can be almost sure that the idea is bad when without an implementor it is not clear if the idea is bad or the implementation is bad. > >So I don't think the chances of this approach working are very good, although it >might be possible if you get exactly the right combination of people. > >A much better approach, in my opinion, is to divide the chess program up into >pieces and give each programmer ownership of one or more pieces. For example >one programmer could be responsible for the book, UI, and learning code. >Another programmer could handle the search & eval etc. I know and this is done with chessbase but the result is bugs that need to be fixed later(long castling bug and Nxe4 problem) when we know only about bugs in the released versions and I can imagine that there are many more bugs that are discovered during the developement and make the developement slower. 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.