An idea: Magic bit count.

[voyagerOne]

Probably thought of before...

When extracting the magic number for move generation... one can use the same magic number and do some bit twiddling to obtain the move count. Killing two birds with one stone.

I don't know just a thought...

Bill

[ZirconiumX]

De Brujin Bitscan is the clostest to what you're talking about.

Matthew:out

[Edmund]

De Brujin Bitscan is the clostest to what you're talking about.

Matthew:out

I think you are missing the point.

A function with ...
Input:
- Occupied squares bitboard
- Square of the slider
Output:
- Squares where the slider can move to (magic bitboard movegeneration)
- Count of the squares where the slider can move to (what the OP is suggesting)

Have read that suggestion before ..
Sure, can make sense for example for mobility calculation. Instead of Popcount(Lookup(sq, occupied)) you only have Lookup(sq, occupied).
Additionally one can apply some more complex weighting with no added cost (e.g. giving a bonus for mobility squares on the opponent half of the board)

Having said that increasing the cache demand also comes at a cost. So after all it boils down to testing the difference.

[voyagerOne]

Having said that increasing the cache demand also comes at a cost. So after all it boils down to testing the difference.

I never understood this...wouldn't a large hash table flood the cache anyways? So the whole point of saving a few bytes is moot, when one has a MB hash table that will "hog" the cache...

Bill

[mcostalba]

It is possible, but the limit of this idea is that it falls short of flexibility.

You almost never want to popcount the simple attacked squares of a slider. You want to popcount the attacks post-processed with something else, for instance removing the squares defended by an enemy pawn (this is quite common) or even something more elaborated.

So for these real world cases the described method cannot be applied.

[Edmund]

Having said that increasing the cache demand also comes at a cost. So after all it boils down to testing the difference.

I never understood this...wouldn't a large hash table flood the cache anyways? So the whole point of saving a few bytes is moot, when one has a MB hash table that will "hog" the cache...

Bill

The size of the hashtable has nothing to do with the proportion of it that gets cached. If your engine has searched hundred different positions, there will at most only be 100 cache lines full with hash entries. The majority gets filled with other stuff - depending on implementation. In the case of magic move generation, given there are 10 sliders per position to generate moves from, these alone will fill 1000 cache lines. Now the more variables that are competing for cache, the more costly refetching has to be done.