PGN-reading code

[Laurens Winkelhagen]

The reason that I decided to make and unmake moves is that even after knowing that a move is legal(I have legal move generator) it is not clear if the move is check or not check and there still may be an error.

It is possible that one Rf2 is Rf2 and one Rf2 is Rf2+ (indirect check) .

When I look at my code of ReadNextMove(a lot of it is also copied from Crafty) I see that one of the conditions to make move is
if (givecheck==0||kingincheck>0)

In other words the case when both happen is also considered as legal
and Rf2 is consider as legal move even if the right move is Rf2+ but Rf2+ is considered as illegal when the right move is Rf2

In other words in the following diagram

[diag]8/8/k7/8/8/8/4R1R1/5BK1 w - - 0 1[/diag]

Rf2 is considered as ambigous and error but Rf2+ is clear.

I am not sure if it is right to do it and my common sense says that Rf2 is clear because no need to write Rgf2 when only one rook can do it without check.

Uri

PGN-specs says that both Rf2 and Rf2+ are ambigous:

http://www.very-best.de/pgn-spec.htm

Neither the appearance nor the absence of either a check or checkmating indicator is used for disambiguation purposes. This means that if two (or more) pieces of the same type can move to the same square the differences in checking status of the moves does not allieviate the need for the standard rank and file disabiguation described above. (Note that a difference in checking status for the above may occur only in the case of a discovered check.)

[Uri Blass]

Uri, one of the reasons I rolled my own was so I wouldn't have to deal with such a long smear from someone else.

What kind of statistics is it you want?
There must be a makemove() somewhere, why not check for the relevant statistics after that?

1)I forgot to reply what kind of statistics I want.

I will give an example.
Movei still does not have knowledge about the blind bishop
KBP when the bishop does not control the right corner.

I want to implement knowledge in the evaluation about it and check for every position in big pgn if it is a draw.

It is important not to have bugs in the knowledge or in other words not to return draw in non drawn positions.

I want statistics about the number of non draw in position that I detect draw and the number of wins for one side in cases that I predict based on evaluation that the opponent has at least a draw.

I may want to implement different knowledge about draws so I may need different statistics.

I want to have different functions for different statistics.

Today I can do it but the problem is that I can do it only with big functions that have a lot in common or by giving some parameter to exsiting function to tell it what statistics to calculate and doing that function bigger every time that I add new statistics and I do not like that solution for astetical reasons.

2)There is another reason reason that I make every move during checking if it is legal.

I already had function to make the user move in game when the same function also check legality of that move.

I wanted to use it when I read pgn because the pgn may also have moves like e2e4 and not only shorter notation.

adding another function only to check the move for legality seems ugly solution.
Maybe it is better also in games not to have one function that check legality of move and make it but having 2 functions when one of them check legality and the second function make it(I already have the second function and I use it often in the search but I do not have the first function).

Uri

[Anonymous]

I will give an example.
Movei still does not have knowledge about the blind bishop
KBP when the bishop does not control the right corner.

I want to implement knowledge in the evaluation about it and check for every position in big pgn if it is a draw.

Uri, I am a bit surprised. I had the same problem (about the wrong B) some years ago, and I asked in CCC. It was Uri Blass, who suggested an excellent rule That rule really works well, and it is very tight - trying to make it even tighter (seeing more draws) will give a few failures (wrong draw score) in all my "simple" attempts. (It is possible, but it is not worth it). Even careful generalization of your rule works very well (double pawn, for example). When opponent has a knight pawn, one has to be careful in generalizing. But still not bad - in this case, one for example could accept few wrong draws - some plies of search will figure out the exceptions.

Here is your rule: http://chessprogramming.org/cccsearch/c ... _id=133811

I repeat - it works perfectly (in that thread, I did not understand very well yet, that exactly no wrong draw claims is important, while one or the other missed draw in static eval is not that bad).

To test such rules: you should implement Nalimov TB-access. It will be much better, than any PGN based stuff. ANd it will be much less work, too.


Regards,
Dieter

[Anonymous]

Sorry, I did not read Uri's post ("blind bishop") carefully enough.

Dieter

[Uri Blass]

The problem is not knowing about correct rules but checking not to have bugs in the code that I still did not write at this moment.

The algorithm is clear but I may have bugs in my implementation when I implement it and the frear from bugs without reliable tool to be more sure of no bugs caused me to prefer other things and not to implement it .

Uri

[Uri Blass]

After thinking about the problem I think that having 2 functions when one of them is only to check if the move is legal without making it and the second one is also to make the move is better.

The reason that I did not do it earlier is that earlier when Movei checked the user input I did not do speical function because it was obvious that the program is going to make the user input in the internal board in case that it is legal immediatly and I did not think that I need special function.

When I added reading pgn in first thought
I did not like the solution of adding a special function to check if a move is legal because in that case I have the same code twice both in checking if the user move is legal and in making the user move.

Later I understood that it is no problem because I can change the function that make the user move in games to first call the function to check if the user move is legal, so I will not have the same code twice and I will probably do it because in case of calculating statistics I may not want to make the move immediatly after checking that it is legal but calculate statistics about every position that have legal move.

The previous solution that I had to calculate statistics like sum of perft was ugly and included reducing the sum of perft after making the last move in the game because I am interested in sum of perft only in positions that have a candidate move.

latest movei still use that solution but it is going to be changed.

Uri