The randomwalk range tests fail for ParIS and Hercules. Digging in, there are actually two separate problems:
ParIS: The range search filters candidates using the on-disk SAX cache (isax_file.sax), but that file gets written with double the records it should (400k for 200k series), so it's misaligned. The filter then compares against the wrong SAX words and throws away real matches (queries lose 75–100% of their results). Recomputing the SAX straight from the raw file instead of reading the cache makes the test pass, which pins it on the cache write in isax_index_binary_file_m.
Hercules: The test builds each case into /tmp/hercules_range__r, but leaves out the thread count, so the thread1/4/8 variants of the same radius share one folder and overwrite each other's index files when tests run in parallel. Run alone it always passes; add the thread count to index_dir and it's green over repeated -j8 runs. So this one is a test bug, not the algorithm.
You can reproduce the issue with:
ParIS:
./build/tests/test_ParIS_Range --gtest_filter="RandomWalkDatar9_thread1*"
Hercules (needs parallelism):
ctest -j8 -R "HerculesRange.*RandomWalk"
Note: the randomwalk query is actually z-normalized despite the filename, so this isn't a normalization issue.
The randomwalk range tests fail for ParIS and Hercules. Digging in, there are actually two separate problems:
ParIS: The range search filters candidates using the on-disk SAX cache (isax_file.sax), but that file gets written with double the records it should (400k for 200k series), so it's misaligned. The filter then compares against the wrong SAX words and throws away real matches (queries lose 75–100% of their results). Recomputing the SAX straight from the raw file instead of reading the cache makes the test pass, which pins it on the cache write in isax_index_binary_file_m.
Hercules: The test builds each case into /tmp/hercules_range__r, but leaves out the thread count, so the thread1/4/8 variants of the same radius share one folder and overwrite each other's index files when tests run in parallel. Run alone it always passes; add the thread count to index_dir and it's green over repeated -j8 runs. So this one is a test bug, not the algorithm.
You can reproduce the issue with:
ParIS:
./build/tests/test_ParIS_Range --gtest_filter="RandomWalkDatar9_thread1*"
Hercules (needs parallelism):
ctest -j8 -R "HerculesRange.*RandomWalk"
Note: the randomwalk query is actually z-normalized despite the filename, so this isn't a normalization issue.