[FEATURE REQUEST]: drop single-point bounds on domain objectives, because they lead to unintelligible errors downstream

[rosonaeldred]

Motivation

Downstream, sometimes have had a user set bounds on a ContinuousOutput feature. If the bounds do not have identical left and righthand sides, then they are generally ignored.

ParEGO/botorch errors out in searching when the bounds reduce the space to have nothing in it.
This will happen due to human error if the bounds get set to constant, e.g.

bounds=(0.0, 0.0)

Error:

RuntimeError, probability tensor contains either inf, nan or element < 0'

Example of automatic assignment of bounds on Outputs to (0,1)

Notice there's no assigned bounds on the Continuous outptu:

domain = Domain.from_lists(
    [
        ContinuousInput(key="component_1", bounds=(0, 10)),
        ContinuousInput(key="component_2", bounds=(0, 10)),
        ContinuousInput(key="component_3", bounds=(0, 10)),
    ],
    [
        ContinuousOutput(key="viscosity", objective=MinimizeObjective()),
        ContinuousOutput(key="hardness", objective=MaximizeObjective()),
    ],
)
s = domain.model_dump_json(indent=2)

#| output: asis
print(f"```json\n{s}\n```")

Dumping to json, you can see they were assigned to bounds=(0,1)
Relevant part of the json:

  "outputs": {
    "type": "Outputs",
    "features": [
      {
        "type": "ContinuousOutput",
        "key": "viscosity",
        "unit": null,
        "objective": {
          "type": "MinimizeObjective",
          "w": 1.0,
          "bounds": [
            0.0,
            1.0
          ]
       }
]

Now assume someone provides a json domain definition with

     {
        "type": "ContinuousOutput",
        "key": "viscosity",
        "unit": null,
        "objective": {
          "type": "MinimizeObjective",
          "w": 1.0,
          "bounds": [
            0.0,
            0.0
          ]
       }
]

Where are bounds set anyway?

MaximizeObjective and MinimizeObjective inherit from IdentityObjective, which explicitly sets Bounds =(0,1)

bofire/bofire/data_models/objectives/identity.py

Lines 11 to 23 in 63e6122

	class IdentityObjective(Objective):
	"""An objective returning the identity as reward.
	The return can be scaled, when a lower and upper bound are provided.
	Attributes:
	w (float): float between zero and one for weighting the objective
	bounds (Tuple[float], optional): Bound for normalizing the objective between zero and one. Defaults to (0,1).
	"""
	type: Literal["IdentityObjective"] = "IdentityObjective" # type: ignore
	w: TWeight = 1
	bounds: Bounds = [0, 1]

Describe the solution you'd like to see implemented in BoFire.

I think if the validator had a more strict requirement than monotonically increasing, that should do it.

bofire/bofire/data_models/types.py

Lines 94 to 98 in 63e6122

	Bounds = Annotated[
	Union[List[float], Tuple[float, float]],
	Field(min_length=2, max_length=2),
	AfterValidator(validate_monotonically_increasing),
	]

STRONGER Solution: drop the bounds on objectives entirely.

[Obviously, will not fix all problems about search spaces being empty, but will catch some problems.]

Describe any alternatives you've considered to the above solution.

Minimally, check the domain for inconsistencies like this and then raise a verbose error.

Is this related to an existing issue in BoFire or another repository? If so please include links to those issues here.

No response

Pull Request

None

[jduerholt]

I am not sure, that I fully understand the problem here. What do you mean by setting bounds on an objective? Can you provide an example code? Best, Johannes

[rosonaeldred]

Hi Johannes, thanks for writing. I edited the description. Does it make sense now?

Sidenote: I am trying to hunt down how bounds get auto set and Claude 4.5 got confused and hallucinated several times, and then it asked me " Could you help me find where in the objectives code the bounds field is actually defined?"

• facepalm *

[rosonaeldred]

Can we drop the bounds on objectives entirely? @jduerholt @R-M-Lee

They are described as optional in the docstring, but then set to [0,1].
" bounds (Tuple[float], optional): Bound for normalizing the objective between zero and one. Defaults to (0,1)."
I also don't know if/where this normalization happens. Does it happen?

We had a case where one output that was an objective (min or max) was measured from [-1, 100]. The error thrown was that the minimum possible for that objective is 0. Why do we enforce a minimum for objectives?

Info from @WaStCo

[jduerholt]

The bounds on the objectives are used here:

bofire/bofire/utils/torch_tools.py

Line 447 in 63e6122

def get_objective_callable(

They are only used in edge cases when one is using for example the AdditiveSoboStrategy. In general you should not touch them at all and keep them always to the defaults [0,1], as in this case the objective value is not modified at all, as the formula is (for maximization)

y* = (y - lower)/(upper-lower), when lower == 0 and upper == 1, you get y* = (y-0)/(1-0)=y

Is this helping?

Best,

Johannes

[rosonaeldred]

The bounds are declared in the docstrings as optional, but are not, because Maximize and Minimize inherit from Identity, which sets them to [0,1]. I don't love having a forced default for an edge case.
I would also like if we could default to no bounds, since they are never/rarely used and (thus) confusing.

The problem I'm bringing up here is it is possible to set the bounds to be constant, [0.0] , and to keep that from happening I'd like to change the validator to block that.

[jduerholt]

Hmm, I do not really get it, if you are not doing anything with the bounds, everything will be fine, or? One can implement None there as default, and if None is provided, it uses 0,1 as this makes the math all the way down easier ...