Passed Pawns (endgame)

[lech]

Thanks Sven, I understood you. I compiled SF without the line 906 and I will try to test it (some, created by me, positions).

[mcostalba]

I have not investigated yet into any modification based on the original code structure since I'm waiting for Marco to possibly come up with his own final cleanup proposal, until now there were some open points. No need to hurry here, of course.

Hi Sven,

please feel free to investigate any modification you may deem interesting in the current code or the cleaned up version from you, at your choice.

If the change turns out to be interesting I will be glad to port that to the current development branch. I am testing the FIXME I have highlighted on my previous post, but until now no luck, so please ignore them and consider current 1.7.1 code as reference (or your version if you prefer because is functional equivalent).

Don't wait for a cleaned-up source to test your ideas because anyway it will be released with the new version.

So the bottom line is don't wait for me. Do whatever you want and it's up to me to take the burden to merge your positive results in the current SF development branch.

[Ralph Stoesser]

@Sven
I think your approach to remove this line

Code: Select all

ebonus += Value(square_distance(theirKingSq, blockSq) * 6 * tr);

will not work in general. It would work for the special cases though. I have played 5000 very fast self play games and the default version was *far* ahead.

After many fruitless tries in that direction (I tried to replace the constant 6 with 5 or 4 and other minor tweaks), right now I try something completely other

replace this ugly special case

Code: Select all

        // Rook pawns are a special case: They are sometimes worse, and
        // sometimes better than other passed pawns. It is difficult to find
        // good rules for determining whether they are good or bad. For now,
        // we try the following: Increase the value for rook pawns if the
        // other side has no pieces apart from a knight, and decrease the
        // value if the other side has a rook or queen.
        if (square_file(s) == FILE_A || square_file(s) == FILE_H)
        {
            if (   pos.non_pawn_material(Them) <= KnightValueMidgame
                && pos.piece_count(Them, KNIGHT) <= 1)
                ebonus += ebonus / 4;
            else if (pos.pieces(ROOK, QUEEN, Them))
                ebonus -= ebonus / 4;
        }

with a new one at the same place in the code

Code: Select all

if (pos.pieces(ROOK, QUEEN, Them) && !pos.pieces(ROOK, QUEEN, Us))
     ebonus /= 4;

That somehow seems to work better in general and it's also ok for the special cases, but not yet enough test games at reasonable time control.

I just wanted to tell you. Maybe you somehow can be successfull with your approach though.

That would be very nice, because what I test right now looks *very* ugly.

[mcostalba]

That would be very nice, because what I test right now looks *very* ugly.

Yes, your code is better then the current one that, although ugly, seems to work at least a bit in my tests. So I have to leave it there.

Just one note. Did you consider that the variation of the bonus with your new code is _completely_ different from the old one ?

Namely the old one just adds/removes a 25% of the bonus, now your new code (that would replace functionality wise the old one) shrinks bonus of 75% !

Did you considered that ?

[Ralph Stoesser]

That would be very nice, because what I test right now looks *very* ugly.

Yes, your code is better then the current one that, although ugly, seems to work at least a bit in my tests. So I have to leave it there.

Just one note. Did you consider that the variation of the bonus with your new code is _completely_ different from the old one ?

Namely the old one just adds/removes a 25% of the bonus, now your new code (that would replace functionality wise the old one) shrinks bonus of 75% !

Did you considered that ?

It is pure coincidence that in my calculation there is also a "4" involved and it is pure coincidence that the formals for some may look somewhat similar.

There is *absolutely* no reference to the deleted code intended!

I have tested other formulas and constants, but so far div 4 seemed to work best.

Please look at the code *thorough* before posting.

My code would not replace the old code functionally.

It is another condition. it is another formula after the condition and it has an other intend!

[mcostalba]

There is *absolutely* no reference to the deleted code intended!

In this case why do you have deleted the old instead of just adding the new one ? If the two code snippets are indipendent you should have done independent testing: remove the old / add the new.

Please look at the code *thorough* before posting.

C'mon don't be hasty I like this sentence, can I use it also myself ? I think it will be needed more often then not !

[Ralph Stoesser]

Marco,

The word "hasty" I donate to you.

This is how I'm used to work, clean-up and bug fix at the same time frame. For such small pieces of code there is not so much risk to make two steps in one task. Also I think it's a good idea of yours to try to remove this a-, h-file special code. Alone from reading Tord's comments I would say this code should not work that good.

So I gave it a try. The next step was the replacement with something completely different that might or might not work. At least it is a try that as a start seems to work. Better ideas are very welcome. I already wrote it.

Regarding your clean-up code a few comments.

I like your FIXME ideas, but what I do not like is your variable naming w.r.t. the local
bitboard variables. It's not your fault, rather mine, because I myself suggested to do so.
Your variable labeling is appropriate.

But after looking at and thinking about it, I would say I much prefer Tord's style.
It's better to read because

- the variable names are very short
- for every variable allocation (b = ...) we see a good understandable source comment about what happens
- later use of the variables (for example (b3 & b4) == b3) is easy to understand *and* easy to read, because elaborate expressions remain short.

Also, and this is most important, this naming scheme is common in many places in the sources. It should be done either one way or the other, but not mixed up. But like I said, I prefer Tord's code style because it's easy to read all over the place.

Just a suggestion, no commitments.

[Ralph Stoesser]

There is *absolutely* no reference to the deleted code intended!

In this case why do you have deleted the old instead of just adding the new one ? If the two code snippets are indipendent you should have done independent testing: remove the old / add the new.

There is another reason why it could be a good idea to remove this piece of code completely w.r.t the thread topic issue and Sven's argument.

Following his argument about the enemy king proximity bonus, and further stating that his rigid attempt to completely remove that bonus would not work in general, but only for the thread issue cases, the next natural step would be to try to only lower this bonus and probably also fiddle with weights regarding enemy square control a little to get things work, whilst not hurting the general case. It's not that easy, but it should work after some trial.

Now this a-, h- file special condition lowers your bonus furthermore, so without this condition your fine-tuning probably would not work anymore. That's the problem. Because you also want to have it work with passed pawns on other files than a or h file.

[mcostalba]

There is another reason why it could be a good idea to remove this piece of code completely w.r.t the thread topic issue and Sven's argument.

Following his argument about the enemy king proximity bonus, and further stating that his rigid attempt to completely remove that bonus would not work in general, but only for the thread issue cases, the next natural step would be to try to only lower this bonus and probably also fiddle with weights regarding enemy square control a little to get things work, whilst not hurting the general case. It's not that easy, but it should work after some trial.

Now this a-, h- file special condition lowers your bonus furthermore, so without this condition your fine-tuning probably would not work anymore. That's the problem. Because you also want to have it work with passed pawns on other files than a or h file.

yes, all very nice, unfortunatly there is the little annoying detail that it doesn't work (I admit is just a small detail): I have removed the special case code and tested and it seems the version with the special case code was stronger, although by not much.

[Ralph Stoesser]

There is another reason why it could be a good idea to remove this piece of code completely w.r.t the thread topic issue and Sven's argument.

Following his argument about the enemy king proximity bonus, and further stating that his rigid attempt to completely remove that bonus would not work in general, but only for the thread issue cases, the next natural step would be to try to only lower this bonus and probably also fiddle with weights regarding enemy square control a little to get things work, whilst not hurting the general case. It's not that easy, but it should work after some trial.

Now this a-, h- file special condition lowers your bonus furthermore, so without this condition your fine-tuning probably would not work anymore. That's the problem. Because you also want to have it work with passed pawns on other files than a or h file.

yes, all very nice, unfortunatly there is the little annoying detail that it doesn't work (I admit is just a small detail): I have removed the special case code and tested and it seems the version with the special case code was stronger, although by not much.

Fortunately I could readd the code, because my attempt is independent from this, because it is a non-functional replacement. Only two lines of code, but it seems you will not look at it anymore.

You seem to be somehow pissed from the other thread.
I have abolutely no intention to harm you.
Come back to earth please...