Glaurung 0.2.4: Binaries!

[Tord Romstad]

Hi all,

I have now updated my Glaurung page with binaries for Linux, Mac OS X and Windows. Thanks to Jim Ablett, Bryan Hofmann and Reinhard Scharnagl for the Windows binaries. I ended up using Bryan's and Reinhard's compiles in the download, because they seem to be the fastest. For serious tournaments, please download from my homepage in order to make sure you have the fastest executable.

The Windows download now also contains the highly experimental FRC version. According to Reinhard, it appears to work correctly in Arena 1.1. If you are feeling adventurous, you can even try using the FRC executable for normal chess. There are two significant additions in the evaluation function of the FRC version: The weight for space and central control has been doubled, and there is a new progressive penalty for multiple passive pieces. This is an attempt to make the program develop its pieces rapidly and aggressively in FRC, but it is possible (though not likely) that it will help in normal chess as well.

The source code distribution has been modified to include the FRC source as well as the normal source.

Tord

[Jim Ablett]

Hi Tord,

Bryan Hofmann's build of Glaurung 024 crashes on my
Athlon XP/M system.

regards,
Jim.

[Jim Ablett]

Sorry my mistake! I'ts fine.

I still had my Arena setup for FRC!

Jim.

[Dann Corbit]

This may be worth a look:
Generating code
e:\pgn\winboard-engines\glaurung\src\see.c(112) : warning C4701: potentially uninitialized local variable 'index' used

[Tord Romstad]

This may be worth a look:
Generating code
e:\pgn\winboard-engines\glaurung\src\see.c(112) : warning C4701: potentially uninitialized local variable 'index' used

GCC also warns about this. For logical reasons which the compiler cannot understand, this is not a problem. The variable will always be initialized. The code looks like this:

Code: Select all

  while(num_of_attackers[side] > 0) {
    /* Locate smallest attacker for side to move. */
    int smallest_value = K_VALUE+1;
    int index;
    for(i=0; i<num_of_attackers[side]; i++) {
      val = PieceValues[Board[attackers[side][i]]];
      if(val < smallest_value) {
        smallest_value = val;
        index = i;
      }
    }
    /* ... */
  }


Note that the body of the 'while' loop will only be executed when num_of_attackers[side] is positive, i.e. if 'side' has at least one attacker. Look at the 'if' statement inside the 'for' loop. Because there is at least one attacker, and this attacker necessarily has a value less than K_VALUE+1, the condition val < smallest_value will always be satisfied at least once before the 'for' loop is finished. This means that the variable named 'index' will always be initialised by the time the 'for' loop exits.

Of course I could easily avoid this warning by initialising 'index' to some value. I think this would be a bit inelegant; I don't want to initialise a variable to a value which is never used.

Tord

[Dann Corbit]

I was not sure if it could be a problem or not.

I think a post-condition assert() would have made it very clear.

[Sven Schüle]

Hi Tord,

of course the compiler can't know that the PieceValues[] array does not contain values > K_VALUE. But even if he could: in my opinion there is nothing elegant in not initializing a variable and then repeating 10 times per day: "Yes, my dear compiler, this variable might be left uninitialized in theory, but I know better."

Similar to what Dann has proposed, I would even have written this:

Code: Select all

  while(num_of_attackers[side] > 0) {
    /* Locate smallest attacker for side to move. */
    int smallest_value = K_VALUE+1;
    int index = -1;
    for(i=0; i<num_of_attackers[side]; i++) {
      val = PieceValues[Board[attackers[side][i]]];
      assert(val <= K_VALUE);
      if(val < smallest_value) {
        smallest_value = val;
        index = i;
      }
    }
    assert(index >= 0);
    /* ... */
  }

The initialization of 'index' does not take extra time, and the 'assert()' is completely empty in a release version compiled with -DNDEBUG.

I think it is an elegant way of programming to let the source code itself show to the reader that it is correct

Lines of code tend to increase by 10-20% if you apply this consistently but at the same time the number of errors, or at least potential errors, reduces by perhaps 50% or more. (No error of course in this case here, Tord!)

Just my 0,02? ...

Sven

[Piotr Cichy]

Hi Tord,

what about this code:

Code: Select all

  while(num_of_attackers[side] > 0) {
    /* Locate smallest attacker for side to move. */
    int smallest_value = PieceValues[Board[attackers[side][0]]];
    int index=0;
    for(i=1; i<num_of_attackers[side]; i++) {
      val = PieceValues[Board[attackers[side][i]]];
      if(val < smallest_value) {
        smallest_value = val;
        index = i;
      }
    }
    /* ... */
  }


Piotr

[Tord Romstad]

Hi Tord,

what about this code:

Code: Select all

  while(num_of_attackers[side] > 0) {
    /* Locate smallest attacker for side to move. */
    int smallest_value = PieceValues[Board[attackers[side][0]]];
    int index=0;
    for(i=1; i<num_of_attackers[side]; i++) {
      val = PieceValues[Board[attackers[side][i]]];
      if(val < smallest_value) {
        smallest_value = val;
        index = i;
      }
    }
    /* ... */
  }


Hi Piotr,

I like this solution. Perhaps I will use it (or something similar) in my next version. Thanks for your help!

Thanks also to Dann and Sven for your suggestions. I have somewhat mixed feelings about using lots of assert() a lot in C. In principle I think it is a good idea, and I use similar constructs all the time when programming in Common Lisp (my native language). When programming in low-level languages like C, however, I am always frustrated by the low information density in the code. I want to pack as much information as possible within each screenful (or printout page) of code, because I find that it makes the code easier and less painful to read. Therefore, I am usually reluctant to use lots of asserts and comments when programming in C.

My preferred way to avoid too many bugs in C is to never attempt to do anything difficult, complicated or clever. I do everything in the most simple and straightforward way I can find. If I am not able to see a reasonably simple way to perform some task, I simply decide that I am using the wrong language, and rewrite everything in Lisp.

Tord