Fire's null_new_depth

Code, algorithms, languages, construction...
mcostalba
Posts: 91
Joined: Thu Jun 10, 2010 11:45 pm
Real Name: Marco Costalba

Re: Fire's null_new_depth

Post by mcostalba » Sat Apr 30, 2011 12:11 pm

fruity wrote: There might still be room to earn some ELO points by only fixing bugs. For example in evaluate.c, evaluate_passed_pawns(..), line 831
Thanks ! Here is the proposed patch.

Code: Select all

Subject: Fix bug in evaluate_passed_pawns()

If blockSq is already on rank 8, blockSq + pawn_push(Us) is on rank 9,
outside of board. It does not make sense to measure king distance to
a field outside the board.

Bug spotted by Fruity:
http://open-chess.org/viewtopic.php?f=5&t=1156&start=10

---
diff --git a/src/evaluate.cpp b/src/evaluate.cpp
index c86af78..82f9c77 100644
--- a/src/evaluate.cpp
+++ b/src/evaluate.cpp
@@ -833,9 +833,12 @@ namespace {
             Square blockSq = s + pawn_push(Us);
 
             // Adjust bonus based on kings proximity
-            ebonus -= Value(square_distance(pos.king_square(Us), blockSq) * 3 * rr);
-            ebonus -= Value(square_distance(pos.king_square(Us), blockSq + pawn_push(Us)) * rr);
             ebonus += Value(square_distance(pos.king_square(Them), blockSq) * 6 * rr);
+            ebonus -= Value(square_distance(pos.king_square(Us), blockSq) * 3 * rr);
+
+            // If blockSq is not the queening square then consider also a second push
+            if (square_rank(blockSq) != (Us == WHITE ? RANK_8 : RANK_1))
+                ebonus -= Value(square_distance(pos.king_square(Us), blockSq + pawn_push(Us)) * rr);
 
             // If the pawn is free to advance, increase bonus
             if (pos.square_is_empty(blockSq))


kranium
Posts: 55
Joined: Mon Aug 02, 2010 10:49 pm
Real Name: Norman Schmidt

Re: Fire's null_new_depth

Post by kranium » Sat Apr 30, 2011 8:12 pm

hyatt wrote:I did not notice critter's name in that list. I only saw a bunch of Rybka/Robo/ip/houdini/etc derivative/clone names. If I overlooked it, it was unintentional. As far as how Houdini's parallel search works, how do you _know_ he developed his own? Ever seen his source? That's the trouble with this entire kit and kaboodle. I suppose we will reach a point where computer chess implodes on itself and interest drops to zero, at least from the developmental side. It doesn't appear to be that far off at the present rate of expansion.

Chris Conkie has provided the best examples of program output showing _identical_ output for some version of Houdini compared to some version of Robo*. Same depths, same PVs, same fail highs, fail lows, etc.... And we are not talking about forced mate positions where one might expect everyone to agree. The fact that an unknown author pops up out of the woodwork, with a program ranked #1, after Robo came out and was ranked near the top as well, is just a bit too much for coincidence. And then the output, particularly for some oddball positions, was revealing since only the robo* family seemed to show the same analysis.

As far as Rybka 4, there is no evidence showing it has almost no fruit/rybka 1 code in it. How much remains is a valid question. Whether any remains or not is the more important issue, as none is allowable...
How about simply labeling these programs as a derivatives?
Testing groups could simply maintain a separate list,
not allowing entrance into serious tournaments..

Why all the fuss and ridicule?
*Because the one's crying the loudest are programmers seeking to discredit any other engines at all cost...
more limelight for them!

Stockfish is 100% original?!
no...maybe a couple years ago.

All programs are benefiting now from the release of IppoLit...
Komodo as well as Fire...and the blessed 'derivative' Stockfish' as well!

IppoLit published to the public domain the most advanced chess programming ideas ever!
a bonanza for the art/science/technology!

Now, after 2 years, IppoLit has been severely pillaged and raped by the chess establishment...
(and especially by these 'puritanical' Talkchess programmers of 'original?' engines)
at the same time they ridicule, exile, and condemn it...!
hypocrites!

yes, rape the messenger, then shoot him!

Norm

mcostalba
Posts: 91
Joined: Thu Jun 10, 2010 11:45 pm
Real Name: Marco Costalba

Re: Fire's null_new_depth

Post by mcostalba » Sat Apr 30, 2011 8:48 pm

fruity wrote: In evaluate_unstoppable_pawns(...) within the first while loop you do not check for enemy pieces blocking a square in front of a passed pawn. In that case you should "give up" on that pawn. There might be more to fix or make better in that function. Passed pawn detection is very ELO critical. So it probably would pay off to invest some serious time there.
Joona noticed that evaluate_unstoppable_pawns(...) is not called or anyhow exits early if the opponent has some piece left.

fruity
Posts: 29
Joined: Wed Feb 02, 2011 12:52 am

Re: Fire's null_new_depth

Post by fruity » Sat Apr 30, 2011 9:31 pm

mcostalba wrote:
fruity wrote: In evaluate_unstoppable_pawns(...) within the first while loop you do not check for enemy pieces blocking a square in front of a passed pawn. In that case you should "give up" on that pawn. There might be more to fix or make better in that function. Passed pawn detection is very ELO critical. So it probably would pay off to invest some serious time there.
Joona noticed that evaluate_unstoppable_pawns(...) is not called or anyhow exits early if the opponent has some piece left.
Don't forget the opponent's king. If opponent's king is on a square in front of our passed pawn, this pawn should be off the race.
In recent implementation you only add +1 to blockerCount in that case, which is wrong.

Another thing I noticed (not critical for ELO):

In line 1006 the condition

if (!pawnIsOpposed && square_file(psq) != square_file(obSq))

can be replaced by

if (!pawnIsOpposed)

User avatar
Uly
Posts: 838
Joined: Thu Jun 10, 2010 5:33 am

Re: Fire's null_new_depth

Post by Uly » Sun May 01, 2011 7:42 am

kranium wrote:Stockfish is 100% original?!
no...maybe a couple years ago.
Original at the source code level. You don't even need to de-compile it or anything, the source is there for everyone to check its originality.

mcostalba
Posts: 91
Joined: Thu Jun 10, 2010 11:45 pm
Real Name: Marco Costalba

Re: Fire's null_new_depth

Post by mcostalba » Sun May 01, 2011 7:46 am

fruity wrote: Don't forget the opponent's king. If opponent's king is on a square in front of our passed pawn, this pawn should be off the race.
In recent implementation you only add +1 to blockerCount in that case, which is wrong.
I have added this to better document the code:

Code: Select all

            // Pawn is passed and opponent king cannot block because path is defended and
            // position is not in check. So only friendly pieces can be blockers.
            assert(!pos.in_check());
            assert(queeningPath & pos.occupied_squares() == queeningPath & pos.pieces_of_color(c));

Post Reply