OpenChess

benstoker wrote:I was looking at Sentinel's Fire code, and null_move.h. It appears as though the null_new_depth function defined in null_move.h is not actually used. The code looks interesting and I was wondering if I am wrong and that the null move routines do indeed use this. Can you enlighten me?

Sentinel wrote:

benstoker wrote:I was looking at Sentinel's Fire code, and null_move.h. It appears as though the null_new_depth function defined in null_move.h is not actually used. The code looks interesting and I was wondering if I am wrong and that the null move routines do indeed use this. Can you enlighten me?

It's an improved idea of Dann's smooth scaling. It's not used in Fire 1.3. In earlier versions it can be activated through UCI parameter (NMR_SCALING).

static const int WBPinValue[16] =
    {
    0, 0, Score(6, 6), 0, 0, 0, Score(4, 4), Score(4, 4), 0, 0, Score(8, 8), 0, 0, 0, Score(15, 15), Score(15, 15)
    };
static const int BBPinValue[16] =
    {
    0, 0, Score(8, 8), 0, 0, 0, Score(15, 15), Score(15, 15), 0, 0, Score(6, 6), 0, 0, 0, Score(4, 4), Score(4, 4)
    };
static const int WRPinValue[16] =
    {
    0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0, 0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0
    };
static const int BRPinValue[16] =
    {
    0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0, 0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0
    };

#define WBPinTarget (bBitboardQ | bBitboardR)
#define WRPinTarget (bBitboardQ)
#define BBPinTarget (wBitboardQ | wBitboardR)
#define BRPinTarget (wBitboardQ)

        if(WRPinTarget & Ortho[b])
            {
            T = between[b][LSB(WRPinTarget & Ortho[b])] & (wBitboardOcc | bBitboardOcc);

            if((T &(T - 1)) == 0)
                Value += WRPinValue[Position->sq[LSB(T)]];
		}

benstoker wrote: ...could you explain what your addition, below, to evaluation.h and .c does?

        if(WRPinTarget & Ortho[b]) // square b is on same rank or file as a bQ
            {
            T = between[b][LSB(WRPinTarget & Ortho[b])] & (wBitboardOcc | bBitboardOcc); // all blockers of both colors

            if((T &(T - 1)) == 0) // 0 or 1 blocker
                Value += WRPinValue[Position->sq[LSB(T)]]; // credit depending on the blocking piece
		}

benstoker wrote:

Sentinel wrote:

benstoker wrote:I was looking at Sentinel's Fire code, and null_move.h. It appears as though the null_new_depth function defined in null_move.h is not actually used. The code looks interesting and I was wondering if I am wrong and that the null move routines do indeed use this. Can you enlighten me?

It's an improved idea of Dann's smooth scaling. It's not used in Fire 1.3. In earlier versions it can be activated through UCI parameter (NMR_SCALING).

Sentinel, while I'm at it, could you explain what your addition, below, to evaluation.h and .c does?

From evaluation.h

Code: Select all

static const int WBPinValue[16] =
    {
    0, 0, Score(6, 6), 0, 0, 0, Score(4, 4), Score(4, 4), 0, 0, Score(8, 8), 0, 0, 0, Score(15, 15), Score(15, 15)
    };
static const int BBPinValue[16] =
    {
    0, 0, Score(8, 8), 0, 0, 0, Score(15, 15), Score(15, 15), 0, 0, Score(6, 6), 0, 0, 0, Score(4, 4), Score(4, 4)
    };
static const int WRPinValue[16] =
    {
    0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0, 0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0
    };
static const int BRPinValue[16] =
    {
    0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0, 0, 0, Score(6, 6), 0, Score(4, 4), Score(4, 4), 0, 0
    };

#define WBPinTarget (bBitboardQ | bBitboardR)
#define WRPinTarget (bBitboardQ)
#define BBPinTarget (wBitboardQ | wBitboardR)
#define BRPinTarget (wBitboardQ)

And in evaluation.c

Code: Select all

        if(WRPinTarget & Ortho[b])
            {
            T = between[b][LSB(WRPinTarget & Ortho[b])] & (wBitboardOcc | bBitboardOcc);

            if((T &(T - 1)) == 0)
                Value += WRPinValue[Position->sq[LSB(T)]];
		}

kranium wrote: I'm convinced that it doesn't actually add any ELO benefit however...
but it makes sense and I couldn't help but add it.

mcostalba wrote:

kranium wrote: I'm convinced that it doesn't actually add any ELO benefit however...
but it makes sense and I couldn't help but add it.

IMHO if it doesn't add any ELO then it doesn't make sense at all to add it.

Anyhow your sentence is interesting because with few words you perfectly synthesize what IMHO is the wrong way to approach engine development, in particular:

1) "I'm convinced that": there is nothing to be convinced, or tests prove it works or prove it doesn't. Stop, nothing more. Tests are the only metric that we apply to evaluate a change.

2) " it makes sense to add": As already explained above, adding stuff with no proven ELO increase is just the fastest way to build up a complete mess out of a good source base.

Of course everybody uses the approach he prefers, my comment simply says that we use a completely different approach in SF and we are happy with that !

kranium wrote: i.e. If your testing techniques are superior, and perhaps empirical....then why is StockFish not as strong than the rest of the field?

kranium wrote:There exists a lot of debate as to:
when does any particular test 'empirically' prove something...?
(especially chess testing at ultra fast TC).

I realize that you believe SF is doing well, and that you have had success with your testing methods,
but maybe you should reconsider them...SF seems to be lagging far behind, and Ippolit source code explains it all quite clearly.

i.e. If your testing techniques are superior, and perhaps empirical....then why is StockFish not as strong than the rest of the field?