Endgame impossible to define in tablebase

Trying to present the puzzle:

White to move. Who wins?

I note that I cannot set up the position in a tablebase. Notice why?

I set up the position on a tablebase with no issues. And it gives a result.

I also had no trouble setting it up. jsaepuru, what was your reason for not being able to set it up?

Note the location of white King and the rook at a1.

The initial position.

There is no inherent reason why they could not have a castling right.

Which endgame tablebases allow castling?

Oh, I just set up the position, didn't add castling to the FEN. Will have to double-check.

Nevermind, white can't castle; it isn't on e1.

The white king started the game on e1. How could it be on d1 without having moved? If it has moved, how could it have castling rights?

One of the sites accepts the queen-side castling option, with the kings moved one file over, but doesn't evaluate it. My guess is that the tablebases exclude positions that allow castling since those are very unlikely in the endgame.

"Tablebases assume that castling is not possible for two reasons. First, in practical endgames, this assumption is almost always correct. (However, castling is allowed by convention in composed problems and studies.) Second, if the king and rook are on their original squares, castling may or may not be allowed. Because of this ambiguity, it would be necessary to make separate evaluations for states in which castling is or is not possible." -- Wikipedia article, "Endgame tablebase"

The OP failed hard on this

Yes - made a mistake about which side King is.

So, with correct handedness:

Problemists would say castling is assumed legal here (the position is possible to reach with white keeping castling rights), white wins.

Practical players and tablebase users would say this position is horrifically unlikely to arise in actual play with white keeping castling rights, so practically white wouldn't be able to castle, black wins.

Smart-alecks would check the FEN for castling rights. Good on them.

The rest of the world passes by.

Choose your allegiance.

Interestingly, study composers with their peculiar endgame positions are one of the most avid user groups of the tablebases. I recall myself having composed a prizewinning study with only the king and a rook with the improbable castling right on the white side. It's a long time ago but I would have been dismayed to discover that the tablebase refused to analyze the critical castling move - had it been around at the time!

In positions where castling is maybe possible, why doesn't the tablebase give 2 solutions -- one which allows castling, and one that doesn't?

Tablebases are not just about 'outcomes' but as much about 'paths' (how to play the variations). It is complicated to mix move-by-move paths with and without castling rights. Think of it not as just 2 different paths but as thousands of them depending on when the castling move is executed and the variations flowing from it.

The proper way is to specify in advance whether or not castling right exists. This can be done in a FEN import-file or -line. Even better would be to do it in the graphical user interface but I am not sure that option is available somewhere.

@Arisktotle, I see your point.  The availability of castling should (ideally) be specified before consulting the tablebase.  But can tablebases be toggled between castling allowed/not allowed?

BTW, the same sort of issue arises with the en passant move.  Without knowing their prior histories, positions possibly involving en passant are ambiguous -- did the pawn that looks capturable by en passant just now move 2 squares?  Do existing tablebases take this into account?  Does even FEN notation deal with this issue?  

I think for castling rights extra tablebases might probably be more practical than introducing parameters into the calling interface. The positions would all be in one variant. So far as I know there no current  EGTBs that include any positions with castling rights.

The FEN contains a field for an en passant square (overspecified) and most GUIs also allow you to enter this as part of the set up. As I understand it the EGTBs take account of the en passant rule.

Though I regularly consult one tablebase and train against another, I am not the ultimate expert. The free 6-men tablebases lack the options of the commercial 7-men elite variety. MARattigan could tell you more about which tablebase supports what toggles.

By the way, The most important and realistis issue is not castling or en passant but the 50-move rule. You might want to specify how many moves have already passed without pawn move or capture (the "pc-count") when the position is presented to the tablebase. As said, MARattigan knows all about that.

Arikstotle wrote:

As said, MARattigan knows all about that.

Very kind of Arikstotle to say so, but I have to disclaim any great expertise in the area.

So far as pc count is concerned there is a very good explanation of how this applies to EGTBs here:

http://galen.metapath.org/egtb50/

And a lot of general info is available via:

https://chessprogramming.wikispaces.com/Guy+Haworth