Problem with bitboard knight attack generator

[Sven]

Nice, by no doubt. But why not this:

Code: Select all

const string PieceToChar("PNBRQKpnbrqk");

i.e. what is the purpose of the dot and the spaces in your version of PieceToChar?

Because PieceToChar must map enum Piece correctly, namely white pawn starts from 1. Instead the dot is there because the same PieceToChar string is used also in print(), and the dot corresponds to a dark square.

But that still means you allow a dot in an FEN string, just for reasons of reusing the PieceToChar map?

Sven

[hgm]

actually I am in a stage of the first version of my GUI and the overhead for parsing and handling a PV has to be 100ms

That really sounds incredibly slow. I would expect this could be done 1000 times faster. Even the quite inefficient WinBoard parser can parse a PGN file with 40,000 games (about 3 million moves) in ~20 sec on a not-so-fast laptop.

[mcostalba]

But that still means you allow a dot in an FEN string, just for reasons of reusing the PieceToChar map?

Yes, I am a very bad guy

And, BTW, if you want to see some spectacular crash you can just place a series of consecutive slashes '/' in the fen. Placing a dot probably would go unoticed (is considered an empty square because it is at index 0, just a guess, not tested). The point is, or you commit to do error handling in fen parsing or you don't...and I don't because I _want_ to assume GUI sends correct fens. If I was developing a GUI probably I'd be more careful, but for an engine it is ok like this, at least it is ok for me.

[hgm]

Most of my engines don't do error checking on FEN, and some don't even do legality checking on moves. Why should they? This is a GUI task, and it makes no sense to duplicate it in every engine.

[Sven]

But that still means you allow a dot in an FEN string, just for reasons of reusing the PieceToChar map?

Yes, I am a very bad guy

And, BTW, if you want to see some spectacular crash you can just place a series of consecutive slashes '/' in the fen. Placing a dot probably would go unoticed (is considered an empty square because it is at index 0, just a guess, not tested). The point is, or you commit to do error handling in fen parsing or you don't...and I don't because I _want_ to assume GUI sends correct fens. If I was developing a GUI probably I'd be more careful, but for an engine it is ok like this, at least it is ok for me.

Multiple slashes do not crash SF, to my surprise (I still have SF2.1 on that PC here):

Code: Select all

bash$ printf "position fen K6k///////////////////////// w - - 0 1\ngo"|./stockfish-21-32-ja.exe
Stockfish 2.1 JA by Tord Romstad, Marco Costalba and Joona Kiiski
info depth 1
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 7 nps 112 time 62 pv a8a7
info nodes 7 nps 112 time 62
bestmove a8a7

Stockfish can also play 9x9 chess:

Code: Select all

bash$ printf "position fen 9/9/9/9/9/9/9/9/7Kk w - - 0 1\ngo"|./stockfish-21-32-ja.exe
Stockfish 2.1 JA by Tord Romstad, Marco Costalba and Joona Kiiski
info depth 1
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 7 nps 152 time 46 pv h1g1
info nodes 7 nps 112 time 62
bestmove h1g1

But two kings are required, though:

Code: Select all

bash$ printf "position fen 9/9/9/9/9/9/9/9/9 w - - 0 1\ngo"|./stockfish-21-32-ja.exe
Stockfish 2.1 JA by Tord Romstad, Marco Costalba and Joona Kiiski
<crashes>

This is subject of personal taste, of course. Both HGM and you say sth. like "crap in - crap out". I say "never crash on external input". That's two completely different positions, and a personal decision which one to follow, in this case for FEN parsing.

Sven

[sje]

I say "never crash on external input".

This is the only good way of doing things. Long, long ago in school I learned the technique as "defensive programming", but by any name it's the best practice.

[Dave_N]

actually I am in a stage of the first version of my GUI and the overhead for parsing and handling a PV has to be 100ms

That really sounds incredibly slow. I would expect this could be done 1000 times faster. Even the quite inefficient WinBoard parser can parse a PGN file with 40,000 games (about 3 million moves) in ~20 sec on a not-so-fast laptop.

I meant to write "much less than 100ms".

The minimum clock interval. There is absolutely no problem with speed.

[Dave_N]

I say "never crash on external input".

This is the only good way of doing things. Long, long ago in school I learned the technique as "defensive programming", but by any name it's the best practice.

I think it depends on the project, if you have X amount of time until alpha (example: your software needs to have a working demo and you can use a laptop / video to show your investors) then why waste time fixing some error checking that is perfectly straightforward when you don't need a playable demo until beta testing, and even then you can wait for someone to complain about the bug because the official release doesn't happen until after a month of waiting for bug reports.

My answer ... the code can be neater if full error checking is done in the first place and sometimes things have to be rewritten.

[Dave_N]

I remember one time I was debugging with message boxes and the message boxes were triggered by a thread that could not exit - and so 100 message boxes appeared in less than a second :S This is why I reserved error handling until later.

[sje]

One must be careful to avoid the unhealthy desire for short term gains which result in high long term costs. Compared to a slower but more sure approach, a rushed project will always cost more and produce results of lower quality.

Full and correct error checking should be performed on all external input, and this checking should be among the very first parts of a project to be coded. If nothing else, at least this will demonstrate that the coders have some understanding of what they are trying to accomplish.

If you work for a company which has the philosophy "there's never time to do it right, but there's always time to do it over", then it's time to look for a new employer.