Author: Sune Fischer
Date: 13:50:12 05/30/02
Go up one level in this thread
>>>If I want to know whether my engine extends too much or not, I will do >>>exactly that - add a test for this. I won't use an array which will be >>>overwritten and crash the program later maybe. >> >>>Sargon >> >>What if you don't have a test position handy? > >Then I try to create one? Or I ask in CCC for one. :) I tend to (try to) solve >things when I think they are an applicatoric problem. (note that a program bug >(array overrun) is not the same as an applicator problem (extend too much) - at >least not in my dictionary. YMMV) Actually, if you have an internal bug, e.g. structures corrupt, then you'll probably discover this bug by crashing in a game or analysis. It is not so different from crashing because of overextending IMO. How do you design a test position for such a failure when it just happens unexpected? >I'm a bit confused.. do you really think it's a good thing to not check array >overruns so that an engine does something undefined (which can be a crash, or >just an illegal move, or formatting your hard drive) Do you mean you constantly verify your structures are not corrupted? Do you check every operation in your program is safe before you do it? That doesn't make sense to me at all, speed matters too much for that. > in case you extend too much >and hope that maybe after hours of debugging you find the reason? Cool. :) And this is where you miss my point I think. I use my knowledge about chess for making the code (surprise eh?:). I know it cannot possibly extend more than X plies because I'm in control of the extension rules, or whatever. Use all the checks you want in a debug build, but in a release build I aim for speed :) Should it crash, then I reproduce the error and track down the bug in the debug build, I do not expect my release build to tell me what went wrong. >>Will you leave the engine running with this debug check forever, just in case? > >Most likely, yes, since I'm not a speed junkie. (no pun intended! :) Chess is an >exponential game (I mean the search tree) and I couldn't care less about a >speed-factor of 1/2500. (your number I think :) Afterall this translates to >something like 0.0x ELO. I try to make my engine stronger, but the primary goal >is that it plays correct moves. ;) Yeah, but I have 10.000 places in my code that needs these checks, I do not plan to sacrifice a factor of 4 in speed "just in case". >>If in your code you have A[B[i]], do you also check that 0<=B[i]<=max, or do >>you *trust* your previous calculation of the data in B[i]? > >(1) I _always_ check input from 'external sources'. E.g. if 'i' could be a user >input, I'd _always_ make a range check before B[i]. Always, always, always. Yes, >also in the release code. Of course, from 'external sources', but I think you know thats not what I meant ;) >(2) Before evaluating A[B[i]] I might add an assert which makes a range check >for B[i] first. This helps me catching engine-internal bugs pretty easy. Once I >have a good feeling and make a release, I _maybe_ compile with -DNDEBUG and the >assert is gone. Yes, that's how I do it too, remove the stupid checks for the screaming fast build :) >>How much safety net do you need, how much speed will you sacrifice to protect >>against the impossible happening? > >As I said before, I'm not a speed junkie. :) I always prefer correct code before >fast code. But what is "safe"? Is it safe to make 1 check, and leave the other 9,999 array calls unchecked? Why is one more important than another? >And guess what? Quite often these two are not mutual exclusive. While >you spend time in the debugger hunting an array overrun, I happily make my >move-sort better. ;) nah, my debug build is massive, I check everything from the adresses of the pointers to the bits on the occupied pawn bitboard, it will catch the error at the move it happens (I hope:). Every move played from the opening position is printed, I can replay it step by step in the debugger if needed. >Sargon > >PS. >Another thing: I've noticed that some people judge the usefulness of a check >(not the chess term :p) by the number of times it fails. (a comon mistake :) I >hope that these people don't work for an airplane company. ;) Strange people, most checks should fail all the time, or else you have one very buggy engine indeed :) -S.
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.