Comments (5)
I'm not quite sure how I feel about that. That would be a lot of extra code to maintain, and you'd have to rationalize that with some pretty juicy features that could be added. Can you explain why you would need a custom BitBoard, so I can make a better judgement call?
That said, if you have an implementation of a bitboard that is somehow better, I'd be more than happy to merge that in.
Keep in mind that a lot of lookup tables (see: magic bitboards) use bitboards, and all the code that you write would have to not break those as well. This would require implementing multiplication, for example, on your custom bitboard type (for the perfect hashing magic bitboards provides). That code needs to be cleaned up regardless, but it would still be an issue.
from chess.
That would be a lot of extra code to maintain
I would expect a Bitboard trait to implement some of the methods of your current Bitboard struct (the ones you need in the algorithms). It will probably just be ~10 lines of code. One would need to change the algorithms that use bitboards to be parametrized over the bitboard type.
But then you just implement it for yours (which is basically already done, just forward the trait methods to the ones of your bitboard), and that allows it to implement it for mine.
Can you explain why you would need a custom BitBoard, so I can make a better judgement call?
Different algorithms for different parts of the engine work faster with different layouts, but you generally want all of them to be able to make correct moves. Chess programming wiki has a lot of info on bitboard layouts, in case you are interested. There are lots of them.
from chess.
One would need to change the algorithms that use bitboards to be parametrized over the bitboard type.
This would be the main problem, not the actual trait itself. In particular, there are many lookup tables that would need to be rearchitectured to work with the trait, which would be difficult.
Note that, the magic bitboards already needs reimplementation. It is very ugly and very slow. However, my plan for fixing it involved generating all those bitboards at compile time. This would not be possible if the BitBoard was a trait (at least not in a way I can think of).
I'll think on it more tonight, and look through what exactly would need to change to get this to work, and I'll let you know.
from chess.
Can't you require those look-up tables in the trait? You have for example in your bitboard implementation the constants edges, ranks, files, ... and you don't provide those at compile time, but generate them at run-time. If you would instead would require in your trait associated functions edges
, ranks
, ... a different bit board implementation could provide those as static constants (instead of mutable statics).
Anyhow, for this to work anything bitboard specific should be accessed through the trait. You can require that information to be in a particular format, so that the rest of the library works. The trivial thing to do would be to require it in the same format than Bitboard uses now.
from chess.
I've looked into this more, and I don't think this is a good fit for this project. I think that it adds complexity, and that I don't see a huge advantage. I'm gonna close this. If you submit a pull request that shows a performance increase given a different bitboard format, I'd be much more likely to consider it. I don't think, however, that I will allow multiple bitboard formats, as there will be a bunch of conversions needed, which I'm pretty sure will erase any performance gains.
from chess.
Related Issues (20)
- En-passant erroneously rejected as invalid when specified via SAN HOT 3
- Move generation is unsound for non-standard positions HOT 1
- Out of bounds square can cause out of bounds access. HOT 1
- Build step is prohibitively expensive HOT 4
- Board.status unnecessarily calculates all legal moves
- Removing en passant doesn't work
- `remove_move` and `remove_mask` truncate moves in the move generator.
- Update source code HOT 1
- Display Game as PGN
- Suggest: add URL to this repo to rust doc
- Repetition in tests
- panic from trying build "1nbqkbnr/1ppppppp/8/8/2PP4/B4N2/P3PPPP/RN1QKB1R b KQkq -"
- Bug in Board Hash trait implementation HOT 3
- [Question] Why does Square allow above 63? HOT 1
- MoveGen throws an IlleganSanMove for a legal move HOT 1
- Promotion moves not implemented in ChessMove::from_san HOT 1
- feat: a to san function HOT 2
- chess::Error should implement std::error::Error
- Incorrect FEN generated: HOT 1
- Defended Piece
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chess.