fix(cmSketch test) and add better cmSketch test #325
Conversation
|
|
|
|
|
This PR has been stale for 60 days and will be closed automatically in 7 days. Comment to keep it open. |
|
It's too bad things like this aren't being fixed. I've seen the logic error copied as part of other language ports. |
|
This PR has been stale for 60 days and will be closed automatically in 7 days. Comment to keep it open. |
|
Anybody? |
mangalaman93
force-pushed
the
frankreh/sketch-effectiveness-tests2
branch
from
98bb8ef to
994e81b
Compare
|
I hope it is clear to anyone reviewing that this test is failing because of the logic bug I pointed out years ago. I had introduced a separate PR to fix that. This PR just highlights the problem more clearly for someone new. |
|
This PR has been stale for 60 days and will be closed automatically in 7 days. Comment to keep it open. |
|
Would like to keep this open until a maintainer can address it or say they don't care. Thanks! |
|
@FrankReh Thank you for your PR. I understand this maybe frustrating but we appreciate the change and will look at it as soon as we can. This is under our watch and we need to spend some time on it for reviewing it. Let me see if we can prioritize it sooner. |
One Sketch test was intended to check that the seeds had caused each
sketch row to be unique but the way the test was iterating, the failure
wasn't going to be triggered.
With this fix, the test passes seeming to indicate the seeds are
working as intended on the row creation. But there is a problem.
A new Sketch test is added that goes to the trouble of sorting the
counters of each row to ensure that each row isn't just essentially a
copy of another row, where the only difference is which position the
counters occupy.
And the new Sketch test is performed twice, once with high-entropy
hashes, because they come from a PRNG, and once with low-entropy hashes,
which in many cases will be normal, because they are all small numbers,
good for indexing, but not good for getting a spread when simply applied
to a bitwise XOR operation.
These new tests show a problem with the counter increment logic
within the cmSketch.Increment method which was most likely
introduced by commit f823dc4.
A subsequent commit addresses the problems surfaced. But as the
discussion from issue dgraph-io#108 shows (discussion later moved to
https://discuss.dgraph.io/t/cmsketch-not-benefitting-from-four-rows/8712 ),
other ideas for incrementing the counters were considered
by previous authors as well.
Fix existing cmSketch test and add improved cmSketch test
(Marked as draft because this introduces a test that fails for now. I can
commit a fix to the cmSketch increment method to get the new test to
pass - if a maintainer agrees there is a problem to be fixed. See dgraph-io#108.
I tried a few years ago.)
One Sketch test was intended to check that the seeds had caused each
sketch row to be unique but the way the test was iterating, the failure
wasn't going to be triggered.
With this fix, the test passes seeming to indicate the seeds are
working as intended on the row creation. But there is a problem with
the actual increment method. A new Sketch test is added that goes
further and sorts the counters of each row to ensure that each row
isn't just essentially a copy of another row, where the only
difference is which position the counters occupy.
And the new Sketch test is performed twice, once with high-entropy
hashes, because they come from a PRNG, and once with low-entropy hashes,
which in many cases will be normal, because they are all small numbers,
good for indexing, but not good for getting a spread when simply applied
with a bitwise XOR operation.
These new tests show a problem with the counter increment logic
within the cmSketch.Increment method which was most likely
introduced by commit f823dc4.
A subsequent commit addresses the problems surfaced. But as the
discussion from issue dgraph-io#108 shows (discussion later moved to
https://discuss.dgraph.io/t/cmsketch-not-benefitting-from-four-rows/8712),
other ideas for incrementing the counters were considered by
previous authors of the original Java code as well.
mangalaman93
force-pushed
the
frankreh/sketch-effectiveness-tests2
branch
from
994e81b to
bca7b61
Compare
One Sketch test was intended to check that the seeds had caused each sketch row to be unique but the way the test was iterating, the failure wasn't going to be triggered.
A new Sketch test is added that goes to the trouble of sorting the counters of each row to ensure that each row isn't just essentially a copy of another row, where the only difference is which position the counters occupy.
And the new Sketch test is performed twice, once with high-entropy hashes, because they come from a PRNG, and once with low-entropy hashes, which in many cases will be normal, because they are all small numbers, good for indexing, but not good for getting a spread when simply applied to a bitwise XOR operation.
Fix existing cmSketch test and add improved cmSketch test
(Marked as draft because this introduces a test that fails for now. I can commit a fix to the cmSketch increment method to get the new test to pass - if a maintainer agrees there is a problem to be fixed. See #108. I tried a few years ago.)
One Sketch test was intended to check that the seeds had caused each sketch row to be unique but the way the test was iterating, the failure wasn't going to be triggered.
And the new Sketch test is performed twice, once with high-entropy hashes, because they come from a PRNG, and once with low-entropy hashes, which in many cases will be normal, because they are all small numbers, good for indexing, but not good for getting a spread when simply applied with a bitwise XOR operation.
Problem
Solution