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
Problem when Sobol falls back to HitAndRunPolytopeSampler #2373
Comments
Thanks for flagging this, this does seem like a bug. I'll take a closer look |
OK so the issue is that the hit and run sampling fallback in Ax (see here currently neither applies the normalization that you mentioned nor, and more importantly, does it apply thinning to the samples, which results in much more correlated samples. Basically, we need to update the Ax logic to call |
Thanks for looking into this. Sounds right, may as well call it directly since it seems to be working fine. When you say thinning what exactly does that mean? Sorry not 100% familiar with all the jargon yet. |
Thinning (removing all but every |
Got it, thanks. |
I've been playing around to try to understand the effect of linear inequality constraints on quasi-random sampling, such as Sobol, and I'm seeing some issues where the samples don't seem to uniformly fill the polytope that is defined by the linear constraints (in addition to the usual box constraints) when
Sobol
is allowed to fall back toHitAndRunPolytopeSampler
. I am wondering if this is related to pytorch/botorch#1225, which was fixed a while back but perhaps the code path that Ax is following to call this sampler is not passing through the proper normalization steps that were implemented?Here's what I mean. First generate a 100-sample Sobol sequence without falling back to the polytope sampler; to make this possible I'll crank up the max number of rejection sampling tries to
1e5
:Producing all 100 generator runs is slow (15 seconds on my computer), probably due to a tiny acceptance fraction during rejection sampling, but the result looks exactly as we'd expect:
If I repeat the experiment above, but setting
"fallback_to_sample_polytope": True
and"max_rs_draws": 0
to force falling back to polytope sampling, the code runs noticeably faster (4 sec), but the results look quite biased towards the corners:As a sanity check, I called this sampler directly and got much more reasonable results, although still not as clean-looking as what you get (very slowly) through rejection sampling:
I'm still pretty new to this so I could easily be doing something wrong, feedback would be welcome!
The text was updated successfully, but these errors were encountered: