Hey Graham, long time. Good to see you're still enjoying CC.
Yes, things move slowly round these parts... would you believe I have a (32bit only) compiled Basic program called Carnage.
It plays worse than TRACE. A 1 sec/move tournament now after 55 games so far puts it 150 Elo behind TRACE. So much for progress!
I can't believe how far the top engines have progressed over the last decade. Incredible.
pedrox wrote:I have tested the position with DanaSah and with different distributions of egbb (egbb6men, egbb5men, egbb4men).
All with dll version 4.1 32-bit
The result is a win for Black.
Gaviota Tablebases indicates draw.
With dll 3.1 and egbb4men danasah has draw.
I took some games from Frank's page, extract some 5-men (around 12k pos) run 5-men sy egtb and add c0 op code in epd based on sy. Here are the resulting epd where 5-men egbb is different.
Could you verify it also?
Ferdinand, I get PRECISELY the same results as you posted...
pedrox wrote:I have tested the position with DanaSah and with different distributions of egbb (egbb6men, egbb5men, egbb4men).
All with dll version 4.1 32-bit
The result is a win for Black.
Gaviota Tablebases indicates draw.
With dll 3.1 and egbb4men danasah has draw.
I took some games from Frank's page, extract some 5-men (around 12k pos) run 5-men sy egtb and add c0 op code in epd based on sy. Here are the resulting epd where 5-men egbb is different.
Could you verify it also?
Ferdinand, I get PRECISELY the same results as you posted...
Ahh OK thank you. You get the epd before my first edit.
Explanation of this typical c0 opcode value
18. 8/3k4/8/8/1n6/1n3P2/5K2/8 w - - c0 "0-1_1/2-1/2"; fmvn 106; hmvc 0; egbb -5191; egbb-rb -5191;
The 0-1 is a win for black but 1/2-1/2 under 50 move draw rule. In this specific case, egbb is right that black would win, but not under the 50 move draw rule.
It looks like these positions are cases where enpassant captures are involved in KPPkp bitbases. I belive i took care of those correctly but something maybe amiss when converting to the new format. I will take a closer look.
This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
Does this mean all the bit bases will need to be regenerated - or just the tables that are KP?KP? ?
Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
After further searches on kp endings, encountered a position where possibility of e.p capture is none, that is after a 2-step pawn push.
Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
After further searches on kp endings, encountered a position where possibility of e.p capture is none, that is after a 2-step pawn push.
But the potential remains for an ep to occur in later moves. That's what I meant by pawn on home square and enemy pawns ahead on adjacent columns - which is how it is in the above position...
Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
After further searches on kp endings, encountered a position where possibility of e.p capture is none, that is after a 2-step pawn push.
But the potential remains for an ep to occur in later moves. That's what I meant by pawn on home square and enemy pawns ahead on adjacent columns - which is how it is in the above position...
Ross
Yes I understand it, what I am actually trying to address (my mistake) is that of all the positions that I found, this is the first time that e.p capture is not possible after a 2-step pawn push.