Issue with tolerance for floating point and its relevance when using log_scale = True about ax

[VMLC-PV]

Just for completeness the trick suggested above by @esantorella works just fine.

multiply the parameters by large constants before passing them to Ax

[esantorella]

Hi! I see how it seems imperfect that the validation is on the parameters in their original scale rather than the log scale, since all the modeling happens on a log scale. However, we have this error because there sometimes are operations on parameters in their original scale. For example, Ax may suggest a candidate that, when serialized or saved, is converted from double to single precision and back. On such a small scale, precision loss can cause the candidate to be outside the bounds.

As a workaround, would you be able to log the parameters and bounds before passing them to Ax and not use the log transform?

[VMLC-PV]

No because of the constraint that I need to use. It's a physics problem so I cannot really get away from it.
if I take the log values of the parameters and bounds (which I usually do) then the constraint does not work with Ax because the constraint would need to be:

10**params3<=` A*(10**params1 +10**params2)

Which, unless I am wrong, does not work, right?
As to the argument about the operations on the parameters in their original scale, if the code first converts things from log to the original scale and back this should not be a problem no?
Basically, only the surrogate model training would see the log scaled value, anything else still gets the real scale ones.
I also feel like most surrogates would perform better when given the log values.

[esantorella]

Oh yes, you're right, nonlinear parameter constraints aren't supported. There's more discussion of this at #153 and in several other issues. Perhaps you could multiply the parameters by large constants before passing them to Ax?

Regarding operations on parameters in their original scale, it's true that modeling only happens in log space. The concern is Ax operations that aren't modeling, which often happen on the original scale. For example, serialization with Pandas in Ax can force float64 data to float32.

[VMLC-PV]

I thought about the multiplication by a large constant. I did not mention it as I was hoping for a more elegant, less 'hacky' solution.
But I understand the issue.
Would be great to have the support for non-linear constraints in Ax too.
For the time being, I'll make it work with the hacky way.
If you think nothing more will happen on this topic, feel free to close the issue. Otherwise, I'll wait some time (in case someone else comes up with something) and then close it myself.
Thanks for the help!

[esantorella]

Another solution would be to use nonlinear inequality constraints in BoTorch and not use Ax. See here on how to set them up and documentation at botorch.org for using BoTorch generally. But that would be considerably more effort than the hacky "multiply by a constant" solution.

I'm going to close this since we have other issues discussing nonlinear inequality constraints in Ax (or rather, their absence), but please feel free to reopen with any additional questions.

[VMLC-PV]

Since nothing will probably happen, I close this issue.
Thanks again @esantorella for the help!