Author: leonid
Date: 04:03:24 11/11/99
Go up one level in this thread
On November 11, 1999 at 02:11:28, Christophe Theron wrote: >On November 10, 1999 at 22:28:49, leonid wrote: > >>On November 10, 1999 at 21:04:11, Christophe Theron wrote: >> >>>On November 10, 1999 at 17:51:07, leonid wrote: >>> >>>>On November 10, 1999 at 13:31:45, Christophe Theron wrote: >>>> >>>>>On November 10, 1999 at 07:15:37, leonid wrote: >>>>> >>>>>> >>>>>>>You can do something faster in assembly, but it takes such a long time to >>>>>>>develop it that in the end you lose your advantage. >>>>>>> >>>>>>>Because chess programming is about being creative, and assembly lengthens the >>>>>>>time between the idea and the implementation. That's the key. >>>>>>> >>>>>>> >>>>>>> Christophe >>>>>> >>>>>>In reality, it is not writing the code that is the most time consuming in >>>>>>programming (at least in mine) but verification of each version of logic. >>>>>>Verification for speed. Writing the code take hardly 5 or 10% from the total >>>>>>time for creating the game. This is why language must have so little impact on >>>>>>the time of writing the chess game. >>>>>> >>>>>>If the last change in my logic took some 5 hours for writing it, after 4 days of >>>>>>verification of positions I still don't know how much advantage I can obtain >>>>>>from the last change. I imagine that the same is true for everybody. This is why >>>>>>I would like to hear from you, or somebody else, how much really the time goes >>>>>>in writing the game compared with everything else. >>>>>> >>>>>>Leonid. >>>>> >>>>>between one and two hours a day. >>>>> >>>>>Anyway that's not the problem. >>>>> >>>>>Here is how I look at it: 100% of the time I spend in my sources is spend >>>>>reading C, not assembly, and for me that makes a big difference. >>>>> >>>>>When I'm not in my sources, I'm not working on Tiger. When my program is running >>>>>automatic tests I work on something else. >>>>> >>>>> >>>>> Christophe >>>> >>>>Can hardly imagine how you do your test. For me the test for speed is the >>>>verification of time that two logics ask for solving the same position. I must >>>>verify big number of positions in order to be certain that response is not >>>>aberration. And deposition of big number of different positions, taken very >>>>often from different sources, take time. To give you one idea about aberration. >>>>The last time I verified the new logic on the first 20 position, just asking the >>>>game to play on its own. The speed improvement was 160%. After this I took the >>>>positions from the Chess Life and tryed the same there on around next 18. >>>>Advantage was hardly 10%. Where I am? I still don't know. Tomorrow will continue >>>>my verification. >>>> >>>>Leonid. >>> >>>Being able to check if a change is an improvement or not is indeed the key to >>>really improve a program. >>> >>>It is very important to invest time to find a good testing methodology. >>> >>> >>> Christophe >> >>Almost impossible. Each time you have some new thing to try. The only way around >>the problem is to give all the try to somebody else. But this is impossible when >>you work on your own. Maybe your situation is different and this is how you are >>spending so much time with your code. >> >>Ho, maybe you could help me in solving my old mystery. Can you describe, in your >>way, at what speed now games search the position? For mate containing position I >>was able to find exact speed, but never found the way to know the speed for >>positional search. It make me wonder how far mine is from the good one. >> >>At what stage is your project? >>Leonid. > >I don't understand your question. > > > Christophe Before I asked two questions. The first one I found already it is really insolvable - speed of positional thinking of the game. The second was about your game, if it is completely finished? Don't be surprise on my question, not everybody finished its game. Leonid.
This page took 0.01 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.