You can set a plies of the game penalty for bringing out rooks or queens.
You can give a bonus for developing knights before bishops.
>Any instructions you give to a human you can give to a computer.<
If that's the case, fortresses wouldn't be an issue, and yet they still are... A human does not need any instructions to assess that fortresses are always dead draws.
>You can give a bonus for developing knights before bishops.<
What would be the exact instruction for that (translated to a layperson).
Lots of engines spend no effort whatsoever trying to determine if one side or the other has a fortress.
For Mike's special Stockfish builds, if there is a FD in the name, that stands for Fortress Detection. In general it makes those engines slightly weaker in game play. On the other hand, if you have a test suite full of fortress positions, it will solve them much quicker.
There are some old versions of Crafty (up to 20.0, but you needed a special compile) which would incorporate Jeremiah Pennery's fortress detection code. This made it solve some problems much faster (e.g. wac.230) but played a bit weaker in game play.
NOW we are at the programmer's decision point. Do I (a) do the fortress recognition stuff? or (b) avoid the computational cost and leave it out? Then the question is, which is more important overall, fortress recognition with much weaker tactical skill or omitting fortresses and gain lots of speed leading to great tactical skill. This kind of trade-off happens all the time. Main thing that has helped is cluster testing where you can actually play enough games to differentiate the Elo of the two programs and make a decision that produces the correct results. Care to guess why fortress detection is not currently included in any program? :)
Stockfish is very bad when it comes to blockades. I can show you a very sloppy blitz game i played where it blocked a winning position against me to a fortress
Not saying it can't or won't ever be done. It is just that the cost is high. But with the speed of today's hardware, this might become moot. Giving up a ply or two out of fifty is not nearly so bad as giving up a ply or two out of 10 or 12. Neural nets were infeasible due to computational cost. Until the GPU revolution which suddenly makes them work.
Take a little walk down history lane:
First programs were selective. VERY selective. Because hardware speeds were so slow a full-width search, even with alpha/beta were simply way to slow.
Flash forward to 1975 and the CDC cyber series computers. Suddenly Slate/atkin were using a full-width search, because faster hardware made it more feasible, and it eliminated the tactical blunders selective search programs made.
Flash forward to the present, and neural net chess programs were infeasible. Too slow. Too tactically blind. Nets could not be anything but very simple due to computation cost. UNTIL suddenly we have hundreds or even thousands of GPU cores. Now a more complex net can be used, and the computations can be done quickly enough to play real chess.
Hard to imagine where the ANN chess programs will ultimately go. Regular alpha/beta has been used for 60 years or so. ANNs are in their infancy. Where will they be in 60 years? Behind alpha/beta still? Or unimaginably stronger? Be interesting to watch this as long as I am able.
In an actual fortress though, it never gets it. So what happens in the non fortress advantages where it after 50+ moves of shuffling around, it deems the position equal, and why does this not happen in real blockades?
For the fortress, it is a pattern recognition problem. Most importantly trying to recognize a fortress where there are superfluous pieces on the board that don't affect anything. IE the side with (or without) the fortress is ahead, but the extra material offers no winning changes. But it "fogs" the fortress recognition code. Tough problem. Same problem in opening books. You take a classic position with white and black that shows up in the opening book. But take the same position with some irrelevant move made (ie a3, etc) and the computer does not recognize that this is basically the same position except for that irrelevant pawn. Again, a similar problem that no one has solved.
The second issue you mentioned is purely search. The 50 move rule is always there, and as you get closer, most programs start to decay the score towards 0.0 (or whatever the draw/contempt setting says). So with no progress, it will realize that it is either going to draw, or else do something that resets the 50 move counter without losing the game in the process...
>take the same position with some irrelevant move made (ie a3, etc) and the computer does not recognize that this is basically the same position except for that irrelevant pawn.<
I was going to ask about that. Doesn't that lead to blunders? Suppose the engine finds a tactical refutation in line A, a line it was intending to play originally. Line B has an innoccous move like a3 added but it doesn't stop the tactic. The engine to move will switch to line B, thinking it doesn't involve the tactic?
They are really that dumb, right?
This also leads them to enter fortresses more often than humans do.
It all depends and wrong knowledge on engines can made them play poorly and can make them prune best moves that NNs (who don't have these commands) do play.
Stockfish can bring up the queen on its second move every game and still beat all humans on earth with ease, so it's a human-created concept.
Mmmm. Stockfish can start with a knight missing from the board and beat every GM on the planet, given powerful hardware.
But this does not mean it is a good idea to toss a knight to start the game.
The real question is, if SF brings out the queen on move two as white, did SF lose the tempo advantage?
I can't say I know the answer for sure, but I guess moving the queen on move 2 is not the best move.
Otherwise, what prevents engines from playing like this without an opening book? Evaluations won't really help that much...
1.d4 d5 2.Qd3 Qd6
This may collide with positions where a pawn chain occupation is better. But regardless, it has nothing to do with bringing the Queen out or not
>If the opening phase has a negative number for any square off of the home row, it will affect where the queen goes<
Fine but the fortress detection parameter is not in the default stockfish version, hence you can't get programming code for when to seek a fortress and when to avoid it (when you're winning). Otherwise it would be ON by default.
even if stockfish prefers the exd4 line with longer ponder time, it still thinks e4 is very good for black. It should have that moved evaluated as 0.00.
1.Nf3 d5 2.e3 Nf6 3.d4 e6 4.Bd3 b6 5.Nbd2 Bb7 6.O-O Bd6 7.a3 Nbd7 8.Qe2 O-O 9.Rd1 Ne4 10.Ba6 Bxa6 11.Qxa6 Ndf6 12.Nxe4 Nxe4 13.Qe2 c6 14.Nd2 f5 15.f3 Nf6 16.c4 Qc7 17.g3 a5 18.b3 e5 19.Bb2 e4 20.f4 a4 21.b4 Qd7 22.Rdc1 Rab8 23.Rab1 b5 24.c5 Be7 25.Kg2 Kf7 26.Rh1 h5 27.h4 g6 28.Nf1 Kg8 29.Rd1 Rfe8 30.Re1 Bf8 31.Rd1 Bh6 32.Nh2 Rf8 33.Rhg1 Bg7 34.Rh1 Rbe8 35.Rhg1 Qa7 36.Rh1 Kh7 37.Rhg1 Rh8 38.Rh1 Re6 39.Rc1 Rb8 40.Rcd1 Re7 41.Rc1 Ree8 42.Rcd1 Bf8 43.Rc1 Qd7 44.Rcd1 Re7 45.Rc1 Rd8 46.Rcd1 Qb7 47.Rc1 Rc7 48.Rcd1 Bg7 49.Rc1 Ra8 50.Rcd1 Ne8 51.Rhg1 Bf6 52.Rh1 Be7 53.Rc1 Kg8 54.Rcd1 Nf6 55.Rc1 Rf8 56.Rcd1 Rd8 57.Rc1 Kh7 58.Rcd1 Rcc8 59.Rc1 Rh8 60.Rcd1 Bd8 61.Rc1 Bc7 62.Rcd1 Rhf8 63.Rc1 Ra8 64.Rcd1 Kg8 65.Rc1 Rfd8 66.Rcd1 Rd7 67.Rc1 Bd8 68.Rcd1 Ra7 69.Rc1 Qc8 70.Rcd1 Rf7 71.Rc1 Ra8 72.Rcd1 Ng4 73.Rc1 Nxh2 74.Rxh2 Bf6 75.Rch1 Raa7 76.Kf1 Qd7 77.Kf2 Qe7 78.Kf1 Rb7 79.Kf2 Qc7 80.Kf1 Qd8 81.Kf2 Rbd7 82.Kf1 Rh7 83.Kf2 Rdf7 84.Ke1 Qe7 85.Kd2 Qd7 86.Ke1 Qe6 87.Kd2 Rd7 88.Ke1 Qe7 89.Kf2 Bg7 90.Kf1 Bh6 91.Ke1 Ra7 92.Kd2 Bg7 93.Ke1 Bf6 94.Kd2 Rf7 95.Ke1 Rg7 96.Kd2 Qd8 97.Ke1 Kh7 98.Kd2 Rg8 99.Ke1 Re7 100.Kd2 Qc7 101.Ke1 Rb8 102.Kd2 Ree8 103.Ke1 Kg7 104.Kd2 Rg8 105.Ke1 Kf7 106.Kd2 Qd7 107.Ke1 Qe7 108.Kd2 Qc7 109.Ke1 Kg7 110.Kd2 Qf7 111.Ke1 Qe7 112.Kd2 Rbe8 113.Ke1 Rgf8 114.Kd2 Qc7 115.Ke1 Kf7 116.Kd2 Rg8 117.Ke1 Rg7 118.Kd2 Kg8 119.Ke1 Rge7 120.Kd2 Qd7 121.Ke1 Bg7 122.Kd2 Bh6 123.Ke1 Rf7 124.Kd2 Ree7
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill