Author: Robert Hyatt
Date: 14:58:43 11/04/02
Go up one level in this thread
On November 04, 2002 at 13:49:00, Vincent Diepeveen wrote: >On November 04, 2002 at 13:29:04, Robert Hyatt wrote: > >>On November 04, 2002 at 09:39:14, Vincent Diepeveen wrote: >> >>>On November 04, 2002 at 06:40:14, Pham Minh Tri wrote: >>> >>> >>>I hardly use asserts in DIEP. If i need one i usually use a >>>printf, which gets removed using a // when it is tested well >>>and a year later or so removed. >>> >>>I guess bob has the same habit. >> >>Actually I have a lot of debugging code in crafty. I surround the debug >>blocks with something like this: >> >>#if defined (DEBUG) >> ... >>#endif > >Exactly, but i don't expect you to make mistakes like next in >your evaluation: > >if( <pattern> && quickboard[sq-5] == blackbishop ) > ... > >Now depending upon pattern that is a possible boundsbug. I suffer from those kinds of problems, because my king safety (for one case) uses two levels of indirection. I compute an index, use that to index an array, modify that some more, use that to index another array. I've had my share of negative and too-large positive values... :) > >However that type of bugs are very common in MOVEI type programs. >Especially the ones not boundschecked. I would not expect you to >make that type of bugs however. Then you would be disappointed. :) > >Most people therefore use loads of asserts to check for example: > assert(sq-5); > >or in 'compatible' Nalimowintel notation: > ASSERT(sq-5); > >>I don't _always_ use DEBUG. I have DEBUGSMP so that I can just get the >>parallel search debug information without all the evaluation and search debug >>info. I also have a bunch of different DEBUG macros for evaluation so that I >>can just get the output from the particular piece of code I am working on. >> >> >> >>> >>>I boundscheck carefully though and if i detect a difference in >>>node count somewhere then i am going to check it out and do not >>>ignore it or claim the compiler is to blame :) >>> >> >> >>I thought you were claiming that the Intel compiler had many such >>bugs? :) >> >> >> >> >>>Note that it is a hard truth that compilers *do* make errors, >>>but in 99.99% of the cases it is a bug in the program, so finding >>>them happens very seldom. Basically i just found out some stupid >>>things in gcc and in intel c++. >>> >>>Best regards, >>>Vincent >> >> >>I think _the_ most common type of bug is unitialized data. That is almost >>_always_ the problem when a program changes its behavior when you insert >>a function call (such as printf()). And these bugs +must+ be found of course, >>or the program will always have a random component in the evaluation that >>will change when optimization level is changed, new functions are called, or >>a new compiler/computer architecture is used... >> >> >> >> >> >>> >>>>On November 03, 2002 at 13:47:57, Vincent Diepeveen wrote: >>>> >>>>>On November 03, 2002 at 12:23:50, Russell Reagan wrote: >>>>> >>>>>Do you have an assert for every index in your program? >>>>> >>>>>If not then a boundschecker might be an idea to try as well :) >>>>> >>>>>>What I usually do to find bugs is use the assert() macro (in assert.h, or you >>>>>>could write your own). Basically what you do is you assert things you know >>>>>>should be true, such as an index into an array being in bounds. If it's false, >>>>>>your program will halt and let you know where the error occured. For example: >>>>>> >>>>>>assert(i < MAX_VALUE); >>>>>>myArray[i] = SomeFunction(x); >>>>>> >>>>>>That way, when you run the program, it will make sure that i is within bounds. >>>>>>The cool thing about this is that it only does this in debug mode. In release >>>>>>mode the assert()'s go away, so there is no speed penalty. In my programs I go >>>>>>crazy with asserts, and put them all over the place, and it helps find some bugs >>>>>>I wouldn't have found without the asserts. Yes, it will run slower in debug >>>>>>mode, but the point of debug mode is to find bugs, not to run fast. >>>>>> >>>>>>Russell >>>> >>>>I agree that use of asserts in everywhere is one of the best experiences to >>>>share (including check bounds). Sometimes my new changes can trigger some dozens >>>>of asserts. Without asserts, my program can run two times slower in debug mode, >>>>but now, it is 20-30 times (in term of nodes per second) as slow as it in >>>>release mode. The big benefit is I can fast develop program, try many new ideas >>>>without worrying much about new errors. >>>> >>>>One of amazing thing to me is that I don't find out asserts in Crafty. So I >>>>guess Bob used a special program to clean up the developing versions before >>>>releasing. >>>>Bob, is it correct? Thanks :)
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.