How strong are TSCP and Faile?

[Uri Blass]

I think I'll try Simon next (if I am able to compile it in Mac OS X). Dan, do you have any estimate of how much weaker it is compared to TSCP?

Hi Tord:

Joshua Shriver did an OS X compile he might share, but I don't think you will have trouble. Platform dependent stuff is all in system.h

I don't any data on how it compares to TSCP. It's weaker than Gerbil and Faile which I think of as more or less comparable to TSCP.

Best
Dan H.

It seems that you do not know tscp if you think that Gerbil and faile are of comperable strength.

Here are rating from the wbec site:

101 Gerbil 0.2 2076
116 Faile 1.4 1918
146 TSCP 1.81 1699


Tscp is more than 200 elo weaker than Gerbil or faile(at least at long time control)

tscp does not like 40/40 and prefers x minutes per game but difference of more than 100 elo is certainly not for that reason.

Uri

[Dann Corbit]

Dann,I can also add that long time control on the slow hardware that you used at that time is equivalent to blitz on fast hardware.

PII300 is probably more than 10 times slower than my A3000

Uri

The machine that gets 14400 seconds for each side is 500 MHz (240 min)
The machine that gets 21600 seconds for each side is 300 MHz (360 min)

On a ten times faster machine than the 300 MHz, it would be ~ G/36
So that would be classified as blitz.

It is amazing how fast the hardware moves forward in a small amount of time.

[Dann Corbit]

{snip}
It seems that you do not know tscp if you think that Gerbil and faile are of comperable strength.

Here are rating from the wbec site:

101 Gerbil 0.2 2076
116 Faile 1.4 1918
146 TSCP 1.81 1699


Tscp is more than 200 elo weaker than Gerbil or faile(at least at long time control)

tscp does not like 40/40 and prefers x minutes per game but difference of more than 100 elo is certainly not for that reason.

Uri

http://www.geocities.com/lyapko/rat30.htm

Code: Select all

 Place Program Elo + - Games Score Av.Op. Draws 
125(-10) Gerbil 2227(-1) 35 34 358 56.4% 2182 10.1% 
152(-13) Faile 2172 26 26 541 41.3% 2233 20.9% 
190(-20) Tscp 2083(-1) 27 28 551 39.8% 2155 14.0% 


There is a big difference in strength between Gerbil 0.1 and 0.2.

Probably, that accounts for the differences in the lists. Most lists will have Gerbil 0.2 by now, and TSCP will also be a different version.

[Pallav Nawani]

Most of the Tscp games were played against weaker programs, and since Elostat ratings are only relative, Tscp has scored a misleadingly high ELO. I don't think Tscp is stronger than 1900 ELO.

Further, Lyapko's ratings do not show the program version. His ratings show Gerbil with an ELO of 2227 and Natwarlal with 2208, and I am quite sure Natwarlal is stronger than Gerbil.

Pallav

[Guenther Simon]

TSCP is around 1800-1900
Faile is around 2050-2100

(for at least a 1Ghz machine)

I played both and my unpublished rating lists which include
me as a Human agree. A lot of rating lists just inflate
the weaker programs and deflate the top programs because
of wrong choice of opponents and missing cross-combination
of player pools.

Guenther

[Dan Honeycutt]

Probably the stuff it is barking about is math on numbers that are too small.

For instance:

unsigned long long Two_to_the_thirty_third = 1 << 33;

Hi Dann:
It can't be that - my compiler would bark if I didn't make that (U64) 1 << 33;

For so many warnings it has to be the arrays - the warning Tord gave as an example was from rand.cpp. That file is nothing but an array. It appears that instead of

U64 array[] = {0x12345678, 0x23456789, ...

Tord's compiler wants

U64 array[] = {0x12345678 ULL, 0x23456789 ULL, ...

Obviously it is treating the numbers as 64 bit. You might not know anything was wrong if it made the random numbers in rand.cpp 32 bit, but Simon's attack patterns and rotated bitboard geometry are in similar arrays. If those values were not 64 bit Simon would be completely brain dead.

Best
Dan H.

[Pradu]

From defs.h in Witz

Code: Select all

//64 bit integer
#ifdef _WIN32
   typedef __int64 int64_t;   // Define it from MSVC's internal type
#else
   #include <stdint.h>      // Use the C99 (ANSI C) official header
#endif
#define U64 int64_t


[Dann Corbit]

Probably the stuff it is barking about is math on numbers that are too small.

For instance:

unsigned long long Two_to_the_thirty_third = 1 << 33;

Hi Dann:
It can't be that - my compiler would bark if I didn't make that (U64) 1 << 33;

For so many warnings it has to be the arrays - the warning Tord gave as an example was from rand.cpp. That file is nothing but an array. It appears that instead of

U64 array[] = {0x12345678, 0x23456789, ...

Tord's compiler wants

U64 array[] = {0x12345678 ULL, 0x23456789 ULL, ...

Obviously it is treating the numbers as 64 bit. You might not know anything was wrong if it made the random numbers in rand.cpp 32 bit, but Simon's attack patterns and rotated bitboard geometry are in similar arrays. If those values were not 64 bit Simon would be completely brain dead.

Best
Dan H.

That's the same problem.

If I have a number like 0x12345678, without a type modifier, it is an int (whatever size that may be). The compiler knows that 64 bit integers should be used to initialize the array, and so it will warn about each constant.

In this case, I don't think that there can be any error, because each integer must promote to the correct type of unsigned long long.

The compiler can still legitimately warn, because of assigning values of the wrong type in the initializer list.

[Alessandro Scotti]

...Tord's compiler wants

U64 array[] = {0x12345678 ULL, 0x23456789 ULL, ...

Hi Dan,
I don't know if there is an easier way around that but here's what I'm using now:

Code: Select all

#if defined(LINUX_I386) || defined(WIN_I386) || defined(MAC_G4)
// 32-bit platform
#if defined(__GNUC__)

typedef unsigned long long  Uint64;
typedef unsigned            Uint32;

#ifndef PRIx64
#define PRIx64  "llx"
#endif

#define MK_U64( n ) n##ull

#else // Visual C++

typedef unsigned __int64    Uint64;
typedef unsigned            Uint32;

#ifndef PRIx64
#define PRIx64  "I64x"
#endif

#define MK_U64( n ) n

#endif
#endif // 32 or 64 bit platform

I find the MK_xxx macro annoying but less than the compiler warning!

[Dan Honeycutt]

Hi Alessandro:

You lost me. I have little knowledge of different platforms. What do PRIx64 and MK_U64 do? When you assign a variable what does it look like:

Uint64 x = 0x12345678;

or something different?

Thanks
Dan H.

[Alessandro Scotti]

Hi Dan,
I use the PRIxxx macros for something like printf( "Nodes = %" PRId64 "\n", nodes ); which becomes "lld" with GCC and "I64d" with Visual C++. I think the PRIxxx's have been standardized in some recent C version that's why I've guarded them with an #ifndef.
Also GCC complains when promoting an integer constant to 64 bits so the MK_U64 macro adds the required size suffix, e.g. BitBoard d_b2g8( MK_U64(0x4020100804020000) ); adds "ull" at the end of the number (for GCC) and eliminates the warning.

[Dan Honeycutt]

Thanks Alessandro, now I understand. What do you do for arrays?

Dan H.

[David Weller]

find/replace: ',' with 'ULL,' worked for me

[Alessandro Scotti]

Thanks Alessandro, now I understand. What do you do for arrays?

I don't have such arrays in Kiwi. A lot of code is still from the original version of early 2000, which compiled with Visual C++ 4.0 and had some trouble with 64 bit constants (IIRC). So all arrays are initialized at runtime, sometimes manually and sometimes from tables of 32 bit numbers. This is very inefficient and cache un-friendly, so I'll have to change it soon or later. For now, the constant I used in the above example is the only one in the whole program...

[Alessandro Scotti]

find/replace: ',' with 'ULL,' worked for me

Yes find/replace is great, but it won't help me with the MK_U64 macro. Instead, when I have to do such changes I load the file with Visual Studio and use one of my favorite "secret" tools: the macro recorder.
I carefully set the cursor position to a known position, e.g. at column 1 of a line I have to change, then press Ctrl-Shift-R to start recording. I do all the changes I need and then make sure I left the cursor ready for another iteration, e.g. at column 1 of the *next* line. Then I click on the "stop" button and press Ctrl-Shift-P to playback the keystrokes... Even the most complex changes on arrays of thousands become a matter of seconds with this method!

[Dan Honeycutt]

I don't have such arrays in Kiwi.

That solves that problem

I think you have answered my question - seems to be no "easy" fix to make all compilers happy. Unless I get more complaints I plan to do nothing. If someone wants to tinker with the program they can find/replace like David did or record a macro like you describe. If someone wants to do a one-shot build like Tord they can ignore the flock of warnings.

Best
Dan H.