-
-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add KS tests for weighted sampling #1530
Conversation
This is sampling without replacement, so expected samples are:
|
…ust-random#1476 Also improves choose_two_weighted_indexed time by 23% (excluding new test)
Approx 2% improvement to tests sampling 2 of 100 elements
This results in approx 18% faster tests choosing 2-in-100 items
I fixed my calculation of the CDF, found a variant which failed like #1476, fixed this by taking the logarithm of keys, and applied some optimisation to the Efraimidis-Spirakis algorithm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks correct. We might want to test how the performance is for big amount
} | ||
|
||
#[test] | ||
fn choose_two_weighted_indexed() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably more complex than needed, but looks correct.
It's probably worth implementing chi squared at some point, but this should also be quite sensitive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably more complex than needed, but looks correct.
You mean the use of an Adapter
? Yes, but I'd sooner do this than revise the KS test API (which is well adapted for other usages).
It's probably worth implementing chi squared at some point, but this should also be quite sensitive.
A fair point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean using KS for these distributions (chi squared would be more straight forward), Adapter I think is fine.
@benjamin-lieser I addressed most of your feedback, using
Best-of-three after (831353f):
Yes, that's a regression, though given that we're using |
I added a benchmark (using weights of Edit: I removed reports of outliers (4-19% so it's clear my machine is not ideally configured for benchmarks, but still good enough for our conclusions). Before this PR (0ff946c; 554d331 is similar):
At d645952 (the first change to
At b806b29 ("keep at most amount candidates", using
At a039a7f (0f662b1 is similar):
At 831353f:
That's not exactly what I expected (my previous changes were guided by the time to run the KS test). According to the benchmarks we would be better off with the code of d645952, however one thing not represented here is memory usage: that old version of I think therefore we should keep using this latest version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should use this version. The other one might be faster in our benchmarks where length and amount are not too large, but it is not true to the idea of the algorithm and users might expect it to have the correct memory footprint.
CHANGELOG.md
entryMotivation
Some of these are non-trivial distributions we didn't really test before.
To validate solution of #1476.
Details
Single-element weighted sampling is simple enough.
fn choose_two_iterator
is also simple enough: there are no weights, so we can just assign each pair of results a unique index in the list of 100 * 99 / 2 possibilities (nothing that we sort pairs since the order of chosen elements is not specified).fn choose_two_weighted_indexed
gets a bit more complicated; I choose to approach it by building a table for the CDF of sizenum*num
including impossible variants. Most of the tests don't pass, so there must be a mistake here.Aside: using
let key = rng.random::<f64>().ln() / weight;
(src/seq/index.rs:392
) may help with #1476 but does not fix the above.