Skip to content

Possible explanation of why CSH doesn't work well #68

@motiwari

Description

@motiwari

First note that the number of points that will be computed exactly is predetermined by the initial batch size, T (assuming infinite sampling budget). Let's call this number of points X.

The number of points sampled looks like:

N, sampled T times
N/2, sampled 2T times
N/4, sampled 4T times
...
...

N/2^r = X points computed exactly (r roughly equals log_2(N/T)).

Now consider the case where the are 2X highly degenerate points that are good candidates for the best arm. In the last step, half of these will get culled -- potentially including the best medoid, due to random noise. For this reason, the last set of X points may not contain the true best arm.

One possible explanation for why this might be a "worse" problem in UCB: in UCB, we see the number of points that need to be computed exactly, giving us a sense of the "degeneracy" of the problem. We likely need to fine-tune T so that X is at least as large as the number of points computed exactly in UCB; any lower, and we will be likely to miss the true medoid.

A lot of this boils down to the "fallback"/"degeneracy" being prespecified by T in the CSH algorithm.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions