Two suggestions for Stockfish

[sje]

Two suggestions for Stockfish:

1. In benchmark.cpp and ucioption.coop, use strtol() instead of atoi(). From the man page:

The atoi() and atoi_l() functions have been deprecated by strtol() and strtol_l() and should not be used in new code.

2. I note the general move generation outputs move by piece kind order, something I used in Spector long ago. I suggest that Stockfish might try an additional trick: within moves by a given piece kind, generate in descending order of center tropism gain.

[zullil]

2. I note the general move generation outputs move by piece kind order, something I used in Spector long ago. I suggest that Stockfish might try an additional trick: within moves by a given piece kind, generate in descending order of center tropism gain.

So for each type of piece, moves the increase centralization appear ahead of moves that don't? To help with move ordering and thus improve the search?

Just checking if I understand what you've suggested.

Thanks.

[sje]

So for each type of piece, moves the increase centralization appear ahead of moves that don't? To help with move ordering and thus improve the search?

Yes. This is a very old heuristic which appeared in a version of Sargon many years ago and was reported in the ICCA Journal. The technique can alternatively be applied in move ordering with an application of a tropismbonus[frsq][tosq] 4,096 element array of bonus/penalty offsets. The latter is used in Symbolic.

[sje]

A third suggestion:

The program currently sets its transposition table size according to a UCI option command. What if the UCI command is not supplied for some reason? What should the default transposition table size be?

In Symbolic, the program sets the transposition table size and other tables by first asking how much physical RAM is available and then initializing the table memory allocation such that about 40% of RAM is used for the entire program.

To fetch the number of bytes in RAM:

Code: Select all

ui64 FetchRamByteCount(void)
{
  ui64 count;

#if HostOsApple
  {
    int mib[2];
    size_t countlen = sizeof(count);

    mib[0] = CTL_HW;
    mib[1] = HW_MEMSIZE;
    sysctl(mib, 2, &count, &countlen, NULL, 0);
  };
#endif

#if HostOsLinux
  {
    const ui pagecount = (ui) sysconf(_SC_PHYS_PAGES);
    const ui pagesize = (ui) sysconf(_SC_PAGE_SIZE);

    count = ((ui64) pagecount) * ((ui64) pagesize);
  };
#endif

#if HostOsUnknown
  {
    count = 1ull << 30;
  };
#endif

  return count;
}

[mcostalba]

A third suggestion:

The program currently sets its transposition table size according to a UCI option command. What if the UCI command is not supplied for some reason? What should the default transposition table size be?

32 MB

In Symbolic, the program sets the transposition table size and other tables by first asking how much physical RAM is available and then initializing the table memory allocation such that about 40% of RAM is used for the entire program.

Too clever for my taste

[mcostalba]

Two suggestions for Stockfish:

1. In benchmark.cpp and ucioption.coop, use strtol() instead of atoi(). From the man page:

The atoi() and atoi_l() functions have been deprecated by strtol() and strtol_l() and should not be used in new code.

Why it is deprecated ?

BTW atoi() is part of the standard C library, so I don't think it will go away soon, say within 50 years from now.

P.S: I hate doing something only because it is written somewhere, if I don't understand why

2. I note the general move generation outputs move by piece kind order, something I used in Spector long ago. I suggest that Stockfish might try an additional trick: within moves by a given piece kind, generate in descending order of center tropism gain.

Well in move generation bitboard is serialized with lsb, so I don't think what you suggest is doable _there_

To try your idea, if I have understood it correctly, we should, instead, alter the move scoring function to score a move according to the psqt difference value: psqt(to) - psqt(from)

I did this in the past, among the trials to modify quiet moves scoring, but I don't remember it was successful...but maybe it was me that wrote a wrong patch.

[sje]

The strtol() function can be set to return a pointer to the first invalid character of the input and this can be useful in some contexts. The function can also handle different input number bases (like hexadecimal). So it's a big step up from atoi() which has no error checking.

And atoi() may go away sooner than you might expect. Besides, I always compile with maximum warning checking and I want to have a clean output. Also, I don't want to have cruft accumulation.

The center tropism metric has been shown to be quite helpful. Depending on the program, it can be subsumed into piece/square tables. This could assign gain bonuses to knights while giving gain penalties to kings.

[Rein Halbersma]

Two suggestions for Stockfish:

1. In benchmark.cpp and ucioption.coop, use strtol() instead of atoi(). From the man page:

The atoi() and atoi_l() functions have been deprecated by strtol() and strtol_l() and should not be used in new code.

Why it is deprecated ?

BTW atoi() is part of the standard C library, so I don't think it will go away soon, say within 50 years from now.

P.S: I hate doing something only because it is written somewhere, if I don't understand why

http://stackoverflow.com/questions/3792 ... v-s-strtol

[sje]

Too clever for my taste

Yet not nearly as clever as some of what's in Stockfish.

Symbolic runs on machines with RAM sizes from 758 MB to 24 GB and will use as much memory as it can without screwing another program which uses the same technique. I don't have to have special versions for different machines and I don't have to remember how much RAM is in a given machine.

[wgarvin]

And atoi() may go away sooner than you might expect.

Neither will billions of lines of legacy C and C++ programs, among which are surely found millions of calls to atoi.

Standards are nice but I think Macro is probably right: atoi will be deprecated forever but I doubt it will actually be _removed_ from standard libraries anytime soon!