RENAMING/REFORMATTING THREAD

[mcostalba]

Use this issue to post renaming suggestions, once in a while, if approved will be committed at once.

We will use a table to make it easier account pending renames.

Please add your renames as new rows in the table. Thanks.

[syzygy1]

In position.h, from_to_bb should be fromToBB.

[snicolet]

• In has_game_cycle(), to and from should be s1 and s2 • trailing spaces in line 1003 of search.cpp

[jerrydonaldwatson]

In the comment here: https://github.com/official-stockfish/Stockfish/commit/3d6995eae8039b2bf4141cbc02d87d5a6c2a1905

we need a space between "//" and "Increase"

[protonspring]

In pawns.cpp, the three basic pawn penalties (Isolated, Backward, and Doubled) area clearly self documenting and don't need their own special comments/spaces. . I propose:

//Pawn Penalties constexpr Score Isolated = S(13,16); constexpr Score Backward = S(17, 11); constexpr Score Doubled = S(13,40);

[snicolet]

Tabs and spaces in line 1167 of search.cpp

[Rocky640]

line 779 of evaluate.cpp, there is an extra space -136 ; --> -136;

[syzygy1]

https://github.com/official-stockfish/Stockfish/blob/a834bfe8332adcb0dfc1fd280f1f9d8bbce86266/src/search.cpp#L953-L955 Since PawnValueEg * (depth / ONE_PLY) is of type Value, the cast to Value is superfluous and should be removed.

[protonspring]

In pawns.cpp, lines 224 and 227, the default value for ourRank and theirRank should probably be RANK_1 instead of 0.

[syzygy1]

@protonspring In that case, it seems that ourRank and theirRank should also be of type Rank instead of int.

[protonspring]

I agree with that.

On Sat, Jun 23, 2018 at 4:31 PM, syzygy1 notifications@github.com wrote:

@protonspring https://github.com/protonspring In that case, it seems that ourRank and theirRank should also be of type Rank instead of int.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/official-stockfish/Stockfish/issues/1426#issuecomment-399714775, or mute the thread https://github.com/notifications/unsubscribe-auth/AcVnSNeFBvJGbS3kCxcGbQ44SGV3FWu0ks5t_sHegaJpZM4SR1Zw .

-- Michael T. Whiteley mobile: 801.707.6886

[Rocky640]

in evaluate.cpp // Bonus for king attacks on pawns or pieces which are not pawn-defended

should be something like // Bonus for king attacks on pawns or pieces which are not strongly protected

or more simply, remove this comment.

[Rocky640]

in evaluate.cpp the Overload bonus and the following comment // Bonus for overload (non-pawn enemies attacked once or more and defended exactly once)

Technically, a piece is "overloaded" (or "overworked") if it has more than one defensive duty. For example, it is needed to defend 2 or more squares, and moving to one such square would leave the other poorly defended. It might also be for example a rook which is needed on the back rank otherwise a mate will follow, and thus cannot defend squares along the file.

This is not exactly what we are computing here.

Suggestions? I was thinking of Pressured, or Tied

[mcostalba]

Drop

include

from evaluate.h

[Rocky640]

In position.h line 479 if (!can_castle(WHITE) && !can_castle(BLACK)) can be replaced with if (!can_castle(ANY_CASTLING)) as we do in search.cpp line 650 and 1670

[Rocky640]

the name "can_castle", although short and sweet, is misleading in 2 ways a) it returns an int, not a bool b) it is only about remaining castling rights, not about the legality of a next move castling

Maybe the longer "castling_rights" would leave no surprise.

Also note that int can_castle(CastlingRight cr) const; is always used as a bool

int can_castle(Color c) const; would always be used as a CastlingRight (an accessor to record the current castling right for a given color) after the change proposed in the post just above

[Rocky640]

In misc.cpp line 231 int get_group(size_t idx) {

this was taken from Texel code

However, in SF, nowhere else do we use names such as get or find

Maybe something like bestGroupForThread

[protonspring]

Line 577 of evaluate.cpp says: "Keep only the squares which are not completely unsafe." This could be much more clear with something more like: "Keep only the squares which are relatively safe." or similar.

[snicolet]

• pawns.cpp, lines 35-37: fix spaces, use alphabetical order • evaluate.cpp: better comments for king tropism

[Rocky640]

material.cpp line 62 there is an extra space before == && pos.count<QUEEN>(us) == 1

[ghost]

https://github.com/official-stockfish/Stockfish/pull/1755

[syzygy1]

In the README, the links to the chess programming wiki should be updated to https://www.chessprogramming.org/Main_Page and https://www.chessprogramming.org/Stockfish

[syzygy1]

between_bb() is still used, so BetweenBB[][] too. Or am I missing something?

[Rocky640]

You are right. I will delete my comment !

[Rocky640]

In evaluate .cpp, we can replace nonPawnEnemies = pos.pieces(Them) ^ pos.pieces(Them, PAWN); with nonPawnEnemies = pos.pieces(Them) & ~pos.pieces(PAWN);

Because under the hood we have this for the first byColorBB[c] ^ (byColorBB[c] & byTypeBB[pt])

And this for the proposed change, so less instructions for the same result byColorBB[c] & ~byTypeBB[pt]

[eduherminio]

from PR #1774 In search.cpp: // Singular extension search (~60 Elo). If all moves but one fail low on a // search of (alpha-s, beta-s), and just one fails high on (alpha, beta), // then that move is singular and should be extended. To verify this we do // a reduced search on on all the other moves but the ttMove and if the // result is lower than ttValue minus a margin then we will extend the ttMove.

[pb00068]

line 913: && !excludedMove // Recursive singular search is not allowed

The comment is misleading, since recursive singular search is allowed and wanted by design, we just not want a vicious cycle at the same ply, so maybe better:

&& !excludedMove // needed to avoid a vicious circle

[pb00068]

The term rBeta is used twice in search:

• in probcut where it means: raised beta
• in singular search where it stands for: reduced beta

This confuses me every time I glance at this variables and prevents me to memorize this 2 different techniques correctly (do we raise or reduce beta in probcut? and what on singular search? ). Using explicit variable names here help's IMO to keep things clear in mind: Probcut -> raisedBeta Singular Extension -> reducedBeta

[syzygy1]

https://github.com/official-stockfish/Stockfish/blob/982fd9c8bce85d4cd8dca32759587d7606385e0e/src/syzygy/tbprobe.cpp#L1110-L1111

There is a c missing in 'aquire', and I think it would be easier to read if "to avoid a thread reads" is changed to "to avoid that a thread reads".

Oh, and in line 1113 exsist should be exist.

[protonspring]

There are some TABS in search.cpp that should probably be converted to spaces.

lines 451, 1189, 1190, and 1191.

[mcostalba]

Time for some roll up. Is there someone interested in flushing this log?

After a possible cumulative patch is applied I will open a new thread. Eventually to avoid threads to become too long and to allow easier understanding of current status, we should close the old one and reopen a new one every time the corresponding cumulative formatting patch is applied.

[protonspring]

I can. Should i make a patch that incorporates all of them?

On Sun, Dec 9, 2018, 1:21 AM Marco Costalba <notifications@github.com wrote:

Time for some roll up. Is there someone interested in flushing this log?

After a possible cumulative patch is applied I will open a new thread. Eventually to avoid threads to become too long and to allow easier understanding of current status, we should close the old one and reopen a new one every time the corresponding cumulative formatting patch is applied.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/official-stockfish/Stockfish/issues/1426#issuecomment-445519400, or mute the thread https://github.com/notifications/unsubscribe-auth/AcVnSNiZ9e-HH5wTZObSHGSvQw_NVTRxks5u3MgUgaJpZM4SR1Zw .

[protonspring]

I made a PR with all of the changes I could find in this issue.

https://github.com/official-stockfish/Stockfish/pull/1861

If you have additions, please either post them in the PR so they can be added, or wait for another (clean) RENAMING issue to be added.

[mcostalba]

@protonspring great! I am going to close this one and reopen a new one