But do you actually need to store all 32GB in RAM?
Minimum material to checkmate at Raumschach ?
Sort:
During generation the EGT is intensively used, mostly through random access (dictated by the moves of the pieces, which bring you to other positions you then want to probe the state of). Hard disks can store much more information, but are several orders of magnitude slower in terms of access time. So it would either take weeks in stead of minutes (using the disk so intensively that it would probably wear out before you are done), or you would need to use a special algorithm that clevely minimizes the number of required accesses, making use of the fact that you will typically read and write information in large chunks (sectors or clusters).
It can be done, (people did 7-men for FIDE Chess), but it is a real challenge.
Yeah, that's why I'm asking, someone had published 7-men generator for FIDE which requires no more than 8GB of RAM(even 3-4gb for pawnless endgames). It took him several days to generate all 5-men, couple of days for 6-men and about month or two for 7-men. That was the numbers I used to estimate. But of course it take him a lot of time to develop it and it was very good optimised. And of course it used HDD, not only RAM.
If there is at least one won position in tablebases that means that it's not insufficient material. It might be won for people but drawn for perfect player, which endgame tables represent
I must say that apart KQ which is trivial and KRR which less obvious but still easy, i have troubles reaching a checkmate with other configurations. Nor does my AI which is not very good at game ending anyway.
I quickly setup a tool to help there, starting from one of the ending setup and playing both sides: http://mi-g.github.io/jquery-jocly/raumschach-eog.html
For a black King on Aa1 the white pieces would have to be at:
KRNK: K Cb2, R Ab2, N Ca1
KNNK: K Cb2, N Ca1, N Ca2
KBNK: K Cb2, B Ac3, N Ca1
KBBBK: K Cb2, B Ac3, B Ac4, B Ad3
KBUUK: K Cb2, B Ac3, U Bc2, U Bb3
KRUUK: K Cb2, R Aa3, U Bc2, U Bc3
KRBBK: K Cb2, R Aa3, B Ac2, B Ac3
etc.
HGMuller wrote:
For a black King on Aa1 the white pieces would have to be at:
KRNK: K Cb2, R Ab2, N Ca1
... KxAb2
K was not in check anyway?
I want to thank __mig__ for the Raumschach board at Jocly, I think this has been a milestone in the history of Raumschach as it makes the game actually playable for the first time, by being able to rotate the board all around very quickly.
You are right, I misplaced theKnight. It has to be on Ca2 to both check and protect the Rook.
HGMuller wrote:
KBUUK: K Cb2, B Ac3, U Bc2, U Bb3
The ones with the Unicorn at Bc2 are interesting. They require a special kind of unlikely 
Not only there needs to be an under promotion as none of the starting U can reach this cell, but there are only two promotion slots that can generate the correct Unicorn, Eb5 and Ed5.
HGMuller wrote:
those that cannot:
R, B, U, RB, BB, RU, BU, NU, UU, UUU
Configurations for KBRK and KBBK, Black King on Aa1:
KBRK = K:Ab3, B:Ab2, R:Bb1
KBBK = K:Ac3, B:Ab2, B:Bb2
I find the second one to be quite the symmetric beauty, each bishop attacking 3 cells in cross fire ways, and the King covering them.
So it would seem only pairs involving a Unicorn can't mate.
In that genarator, yes (approximately). The number of positions is 125 to the power 5, which is 30.5 billion. The generator uses one byte per board position, where the byte contains both info for white (strong side) to move in that position, and black to move.
This can be done more efficiently by representing the EGT as a bitmap, using only a single bit per position. 30.5 billion bits fit in under 4GB. You would then need separate bitmaps for the white-to-move and black-to-move positions, and you could flush out the bitmap for mated-in-N to disk as soon as you have used it to generate the correponding part of the mated-in-(N+1) bitmap.
In FIDE Chess 64^5 is only 1 billion, and a bitmap would be 128GB. You can save on that by exploiting symmetry (8-fold in in FIDE, 48-fold in RaumSchach), but that introduces a lot of complexity, and it will lose generality (boards might not be square, pieces might move asymmetrically).
Of course once you have generated the EGT, you can compress the information further. Especially if they are bitbases (containing only W/D/L or even win/non-win info) you can ofteh reach enormous compression factors, because virtually all positions are won, or all are lost. But doing so during generation would introduce an enormous amount of overhead, and would not help that much, because the ratio undecided / assigned positions changes all the time. So I never tried that.