Skip to content
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

Merge order affects recommendation order #353

Closed
Scienfitz opened this issue Aug 29, 2024 · 0 comments · Fixed by #370
Closed

Merge order affects recommendation order #353

Scienfitz opened this issue Aug 29, 2024 · 0 comments · Fixed by #370
Assignees
Labels
bug Something isn't working

Comments

@Scienfitz
Copy link
Collaborator

Scienfitz commented Aug 29, 2024

Recommendations are expected to be provided in the order that the recommendation algorithm defines. Especially in greedy algorithms the order has meaning and should be preserved.

Currently, the order of discrete recommendations is changed by the merge to the searchspace, which should be fixed. Likely, this can be achieved by swapping left and right in the respective merges.

@Scienfitz Scienfitz added the bug Something isn't working label Aug 30, 2024
@Scienfitz Scienfitz self-assigned this Aug 30, 2024
Scienfitz added a commit that referenced this issue Sep 7, 2024
Fixes #353 

Unintended reordering of discrete search space parts in
`BotorchRecommender` was caused during pd.merging by the searchspace
being on the left, however it should be on the right and the merge is
safest done with `how='left'` while having the numerical points returned
by botorch on the left -> the resulting rows will follow their order.

A test has been written, perhaps though a little too complicated but
anyhow. We can construct a searchspace/target construct where it would
be expected that the order of the searchspace is strongly broken when
getting recommendations (although I havent been able to create one that
is exactly anti-ordered). In the faulty variant the recommendation order
would still be monotonically increasing like in the searchspace, while
the "correct" order is roughly anti-ordered, or strictly speaking `not
monotonically increasing`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant