Added option to use 4GB to skip hash searches

[klutt]

A friend of mine told me that this were the proper way to do this.

[smack42]

This doesn't work. 4 billion entries are required in the complete table: 256_256_256*256=4.294.967.296

With 4 bytes per entry that table uses 16GB. Use unsigned char instead of unsigned int for Entry.depth to reduce it to 1 byte per entry for a total of 4GB.

For a data structure that is both compact and fast, have a look at a map that uses a trie instead of hashtable for its keys.

[klutt]

You are completely right. Thank you. Maybe I'll change that tomorrow.

Some memory could be saved however. I see three ways of doing this.

Firstly, the four tiles in the middle will not be used. This could bring it
down to 252⁴=4.032.758.016.

Secondly, two robots can never use the same tile. This brings us down to
252_251_250*249=3.937.437.000. It's not a fantastic reduction, but it's
still about 300MB.

Thirdly, and here I'm not 100% sure but almost, the positions 0x00010203,
0x00010302, 0x00020103 etc are the same positions. There are 4!=24
permutations of all positions. This can reduce the memory needed
dramatically with a factor 24, so we end up at 3.937.437.000/24=164.059.875
or about 164MB.

Of course this will require some function to translate the position, but
the dynamic allocation is gone, and what's more important, all entries can
be accessed in constant time because a search is not needed.

On Mon, Sep 2, 2013 at 9:22 PM, Michael Henke notifications@github.comwrote:

This doesn't work. 4 billion entries are required in the complete table:
256_256_256*256=4.294.967.296

With 4 bytes per entry that table uses 16GB. Use unsigned char instead of unsigned
int for Entry.depth to reduce it to 1 byte per entry for a total of 4GB.

For a data structure that is both compact and fast, have a look at a map
that uses a trie instead of hashtable for its keys.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3#issuecomment-23675279
.

[smack42]

While the first two of your ideas to reduce memory are known and can be used as-is, the third idea is good too, but you can't swap the positions of all 4 robots, only those of the 3 non-active robots. This is already implemented in function make_key by sorting the positions. As you said, you need a transformation function to make it work with your static array.

Btw. Michael Fogleman published a presentation about the algorithm used in his program: https://speakerdeck.com/fogleman/ricochet-robots-solver-algorithms

My program uses nearly the same algorithm - it's the fastest and least memory-consuming that I currently know. However, I don't like the hashtable so I implemented the map using a trie (TieMapByte.java here: https://github.com/smack42/DriftingDroids)

Have fun!