Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Total Invisibles: don't fail assert()s that we tried to add in #433 #437

Open
thomas-maeder opened this issue Dec 21, 2023 · 2 comments
Open
Labels

Comments

@thomas-maeder
Copy link
Owner

See #433

@thomas-maeder thomas-maeder changed the title Total Invisibles: don't break assert()s that we tried to add in #433 Total Invisibles: don't fail assert()s that we tried to add in #433 Dec 21, 2023
@JoshuaGreen
Copy link
Collaborator

Before we go too crazy here, I'd like to emphasize some points.  My

assert(en_passant_was_multistep_played(entry->u.ep_capture_potential.ply));

assertion (which when paired with a correction to en_passant_was_multistep_played strengthened @thomas-maeder's

assert(en_passant_top[entry->u.ep_capture_potential.ply]>0);

assertion) captured what seems like a logical assumption, namely that we should never try to remove an en passant square that we didn't actually add.  On the other hand, my

assert(entry->u.ep_capture_potential.ply>=nbply);

assertion primarily reflects a limitation of our en passant infrastructure.  It's conceivable that some solving requires us to manipulate rangers earlier than nbply, and in that case it would be the en passant infrastructure that would have to be appropriately updated to accommodate that.

@thomas-maeder
Copy link
Owner Author

@JoshuaGreen I think this issue is obsolete. Do you agree?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants