Interpretability of target transformations

[AdrianSosic]

It's been reported that target convenience constructors sometimes give an unintuitive (yet correct!) result.

For example, when creating a "minimization" target of the following kind, the corresponding minimize flag appears as False, because the inversion is done via the transformation:

target = NumericalTarget.normalized_ramp("Biproduct", cutoffs=(0, 100), descending=True)
assert target.minimize is False

Also, specifically for the ramp constructors, it appears surprising that they take a descending flag instead of a minimize flag.

While non of this is a "bug", we might want to replace the inner construction and the interface so that they are more in line with what user would expect.

[Scienfitz]

Also, specifically for the ramp constructors, it appears surprising that they take a descending flag instead of a minimize flag.

I don't really see this, why is that surprising? It is just important if the top of the ramp is left or right with mimimize always being False.

While it could be interpreted as a flip (and shift to be fully equivalent) - I don't think that is more natural. What exactly do you want to replace it with?

[AdrianSosic]

I reconsidered a little and now think that what's actually missing (i.e. non-breaking change) is perhaps simply the minimize argument. You know, while the current functionality is complete in the sense that you can model all cases, it does not implement the "separation of concern" approach explained in the userguide, i.e. 1) define what is your signal to be optimized and 2) say if you want to maximize/minimize it.

So from an application point of view, it might still happen that the "natural" way to describe the ramp is increasing but you still want to minimize it, in the spirit mentioned above. So for example, you could have a physical target "Amount" and the signal you're interested is Saturation (i.e. naturally increases with increasing "Amount"), but you want to minimize it. Hence, it's unintuitive to set the ramp in reverse direction, only to get the minimization running.

Would solve both my problems from above without any breaking changes. What do you think?

[Scienfitz]

ok so you simply want to add minimize to the constructor?

Seems fine to me, its redundant but this is true for many construction ways of targets and its not breaking so I'm fine with it.

One just has to make sure that the desriability objective correctly shifts it into the normalized interval but I think thats the case