duncan wrote:
question to daniel jose. I tried to 'educate' the hash by setting it this position
[d]4k3/2pp1ppp/4p3/8/3P4/3Q4/PPP1PPPP/RNB1KBNR b KQ - 0 2 and waiting till it found the mate in 11.
saved the hash and reloaded it. however it still did not find the mate in 11. do you know why this is ?
A request for clarification:
You had the engine search the position above until it showed that, after any move by Black, the position is mate-in-9? You then saved the hash, restarted the engine, loaded the saved hash, and gave it the following position?
[D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1
duncan wrote:
question to daniel jose. I tried to 'educate' the hash by setting it this position
[d]4k3/2pp1ppp/4p3/8/3P4/3Q4/PPP1PPPP/RNB1KBNR b KQ - 0 2 and waiting till it found the mate in 11.
saved the hash and reloaded it. however it still did not find the mate in 11. do you know why this is ?
A request for clarification:
You had the engine search the position above until it showed that, after any move by Black, the position is mate-in-9? You then saved the hash, restarted the engine, loaded the saved hash, and gave it the following position?
[D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1
If so, what were you expecting to happen?
I saved the hash for this position [D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1 after it had found a mate in 12.
reloaded the hash and gave it this position [d]4k3/2pp1ppp/4p3/8/3P4/3Q4/PPP1PPPP/RNB1KBNR b KQ - 0 2 and waiting till it found the mate in 9 .
saved the hash and reloaded the hash and gave it this position [D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1
hoping it would find the mate in 11 within a few minutes. It did not find it even after a few hours.
(finally found the mate in 11 AFTER I had done the above. computer slowish. though would still like to know what I am doing wrong for the future)
BeyondCritics wrote:There is new flag, that forbids stockfish to clear the hash. Did you set it on?
Please always tell, how big your hash file is, this is highly significiant. Make it as big as possible. I use typically sizes in the giga bytes.
A Hash table in a chess program is a probabilistic data structure, that does not promise anything, not even a correct entry. Take this into account.
If you use persistent/sticky hashing, you are required, to only search root positions, which are related somehow. Otherwise you will get into deep trouble in the long run.
never clear hash is ticked.
1000 mb hash
you say
"If you use persistent/sticky hashing, you are required, to only search root positions, which are related somehow." I am not sure what I should be doing
duncan wrote:
question to daniel jose. I tried to 'educate' the hash by setting it this position
[d]4k3/2pp1ppp/4p3/8/3P4/3Q4/PPP1PPPP/RNB1KBNR b KQ - 0 2 and waiting till it found the mate in 11.
saved the hash and reloaded it. however it still did not find the mate in 11. do you know why this is ?
A request for clarification:
You had the engine search the position above until it showed that, after any move by Black, the position is mate-in-9? You then saved the hash, restarted the engine, loaded the saved hash, and gave it the following position?
[D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1
If so, what were you expecting to happen?
I saved the hash for this position [D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1 after it had found a mate in 12.
reloaded the hash and gave it this position [d]4k3/2pp1ppp/4p3/8/3P4/3Q4/PPP1PPPP/RNB1KBNR b KQ - 0 2 and waiting till it found the mate in 9 .
saved the hash and reloaded the hash and gave it this position [D]4k3/2pppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1
hoping it would find the mate in 11 within a few minutes. It did not find it even after a few hours.
(finally found the mate in 11 AFTER I had done the above. computer slowish. though would still like to know what I am doing wrong for the future)
Perhaps your expectations are unrealistic? After finding the mate-in-9, you saved the hash. So, when you reloaded that hash and searched the original position, the engine now had an exact score (mate-in-9) for that one position. I wouldn't expect that knowledge to be all that helpful in determining the evaluation of the original position. There are so many other nodes that still need to be considered.
BeyondCritics wrote:There is new flag, that forbids stockfish to clear the hash. Did you set it on?
Please always tell, how big your hash file is, this is highly significiant. Make it as big as possible. I use typically sizes in the giga bytes.
A Hash table in a chess program is a probabilistic data structure, that does not promise anything, not even a correct entry. Take this into account.
If you use persistent/sticky hashing, you are required, to only search root positions, which are related somehow. Otherwise you will get into deep trouble in the long run.
never clear hash is ticked.
1000 mb hash
you say
"If you use persistent/sticky hashing, you are required, to only search root positions, which are related somehow." I am not sure what I should be doing
OK, 1Gb looks reasonable to me.
You should just be aware of the fact, that saved "unrelated" searches are detremial for search performance. With "unrelated" i mean a completely different board position. If you are doing performance experiments, this is an important "factor" for the outcome.
So i would do it exactly as you described and taking care, not to search a different board position with this same hash table loaded. I would clear the table before any experiment.
Of course, a carefull controlled "robustness" experiment would be feasable too.
Rodolfo Leoni wrote:BTW, I just tested AsmFishW save and load hashes: it doesn't work at all, even if no move is made.
I just tested the Linux version. TTSave worked. TTLoad did not---until I discovered that the file created by TTSave had permissions 000. Once I made the file readable, TTLoad worked.
Then, a more interesting test you could run could be, with little hash size:
a) let AsmfishW analyze a position until a consistant fail high/low happens.
b) save hash
c) close and restart GUI
d) load hashes and chech if AsmFishW hits the fail high/low immediately.
Here, it didn't work. I'm curious if it works under linux.
Actually, I'm beginning to have some doubts too. So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...
Definitely seems like there are issues here. Using a saved hash seems to hinder the search rather than help it. Load followed by immediate save produces a file different from what was loaded, which seems odd ...
Received confirmation that hash save/load in asmFish are broken:
I just found that the ttload/ttsave functions are completely broken. Easy to fix though.
Rodolfo Leoni wrote:BTW, I just tested AsmFishW save and load hashes: it doesn't work at all, even if no move is made.
I just tested the Linux version. TTSave worked. TTLoad did not---until I discovered that the file created by TTSave had permissions 000. Once I made the file readable, TTLoad worked.
Then, a more interesting test you could run could be, with little hash size:
a) let AsmfishW analyze a position until a consistant fail high/low happens.
b) save hash
c) close and restart GUI
d) load hashes and chech if AsmFishW hits the fail high/low immediately.
Here, it didn't work. I'm curious if it works under linux.
Actually, I'm beginning to have some doubts too. So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...
Definitely seems like there are issues here. Using a saved hash seems to hinder the search rather than help it. Load followed by immediate save produces a file different from what was loaded, which seems odd ...
Received confirmation that hash save/load in asmFish are broken:
I just found that the ttload/ttsave functions are completely broken. Easy to fix though.
Rodolfo Leoni wrote:BTW, I just tested AsmFishW save and load hashes: it doesn't work at all, even if no move is made.
I just tested the Linux version. TTSave worked. TTLoad did not---until I discovered that the file created by TTSave had permissions 000. Once I made the file readable, TTLoad worked.
Then, a more interesting test you could run could be, with little hash size:
a) let AsmfishW analyze a position until a consistant fail high/low happens.
b) save hash
c) close and restart GUI
d) load hashes and chech if AsmFishW hits the fail high/low immediately.
Here, it didn't work. I'm curious if it works under linux.
Actually, I'm beginning to have some doubts too. So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...
Definitely seems like there are issues here. Using a saved hash seems to hinder the search rather than help it. Load followed by immediate save produces a file different from what was loaded, which seems odd ...
Received confirmation that hash save/load in asmFish are broken:
I just found that the ttload/ttsave functions are completely broken. Easy to fix though.
The bugs in the ttload/ttsave functions were fixed by @tthsqe12 with commit 222d48c.
The executables of 05Aug contain these bug fixes.
Anyone know who tthsqe12 is? Is that Mohammed?
Just to clear misunderstandings. AsmFishW has the save/load hash feature, but its hashes aren't "persistent" as Stockfish savehash by Daniel. The concept is different. In traditional hashes (example, AsmFishW) newest entries will overwrite oldest ones. In persistent hashes (Stockfish savehash) more valuable entries will overwrite less valuable ones. This, only in infinite mode.
So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...