Enable single point precision via env vars

[Scienfitz]

Added

• env var for torch
• env var for numpy
• these are booleans that enforce usage of single precision if True, False by default

Addressing suggestion from #223

Notes:

• Did some very light testing via fulltest and setting the tox env vars to use single precision there
• some tests expectedly fail due to numerical instability -> no action required
• some tests fail because hypothesis generate incompatible floats --> likely fixed by using st.floats(...,width=32) if single precision is desired --> not done under the assumption we dont want tests enabled for single precision, would require flexible checking everywhere
• some tests fail as constraints complain about combining Single and Double precision --> likely because rhs and coefficients are defined as python floats, hence 64 bit. This means using double precision with env vars also implies providing explicit 32bit floats in such fields (like coefficients or rhs), otherwise it wont work. This is not something I'd fix but perhaps mention in the userguide

[AdrianSosic]

Hi @Scienfitz, thanks for implementing. I think the changes are completely fine 👍🏼 However, we should perhaps discuss your statements from the PR description:

• Agree with statement about failing tests due to numerical instability
• Don't fully agree with statement about user input. I think the choice of the float-type should be entirely a backend thing and should not require changing inputs by the user (which is annoying + requires us to write explanations in the user guide + requires people to find these explanations). But I also don't think that a proper implementation is complicated / requires much effort. The continuous constraint is a perfect example: Instead of converting the user input (which would then cause potential problems with roundtrip serialization) I think the conversion simply needs to happen in the corresponding compute calls, i.e. in this case in to_botorch, where the coefficients are already correctly converted. That means, adding a simple torch.tensor(self.rhs, dtype=DTypeFloatTorch should already suffice!? The only place I see where a "delayed" conversion is not possible is in the attributes of the discrete search space. But there we could in principle set appropriate eq-checks into place, if needed in the future.
• Because of the above, I think we can omit float32 tests for now but if we notice the first problems, we still add them later.

[Scienfitz]

@AdrianSosic
please make a thread and not a PR comment for discussion matters

[AdrianSosic]

Great, thanks for taking the time to dive into the botorch issue. Send me the link to the issue once it's online so I can subscribe 👍🏼