[tune] Fix hpo randint limits

[krfricke]

Why are these changes needed?

HyperOpt actually supports broader limits for randint.

Related issue number

Checks

• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[sumanthratna]

looks perfect, assuming tests pass—thanks @krfricke

[sumanthratna]

@krfricke the CI errors made me realize—this is a breaking change, right? This should be a pretty easy fix for tune users but if we really want to stick to semver maybe we should change low to a kwarg (low=0, high... instead of low, high..). not really sure what the best option here is

[krfricke]

Is it a breaking change? As I see it it just affects the search space conversion, and Tune's randint definition always included a lower and a upper bound. Behavior on hyperopt's side is not affected, is it?

[krfricke]

But I guess we could pass kwargs to hyperopt. instead of args to be sure. Can you update the PR?

[richardliaw]

I think this is backwards compatible, so it's safe to include without modifications to signature.

[richardliaw]

tests failing though

[sumanthratna]

Tune's randint definition always included a lower and a upper bound. Behavior on hyperopt's side is not affected, is it?

Ahh yup that's my bad; I forgot we had our own lower arg. You're right, this isn't a breaking change

But I guess we could pass kwargs to hyperopt. instead of args to be sure. Can you update the PR?

sure, is c142b85 what you were expecting?

---

edit: whoops, just saw this:

I think this is backwards compatible, so it's safe to include without modifications to signature.

happy to revert part of the kwarg commit to stick to args for the signature