industrial-optimization-group / desdeo-problem Goto Github PK

Consider having them all be one or the other?

we need to add "return_std= True" to model.predict(decision_vector) to have the uncertainty information as well. otherwise, we get an error when we want to use this function.

No option for maximization, default is minimization.

Recently added test problems should be added to the __init__.py file located in the testproblems module. Each function generating a test problem should be imported as done here and the function name should be added to the list stored in the __all__ variable here.

By adding this enhancement, we can import test problems from the testproblems module easily as such: from desdeo_problem.testproblems import ProblemName.

A method should be implemented in MOProblem which checks whether each objective is supposed to be minimized or maximized. This information is purely informational. Problems, and thus objectives, should be defined in DESDEO in minimization form.

The type (hint) signature of the method should be:

def get_objective_directions(self) -> List[bool]
...

The tests test_evaluate_gaa and test_evaluate_multiple_clutch_brakes are not passing. The tolerance of the comparison to the expected value should be fine tuned. We arrived to the conclusion with @maaviixu earlier, that the code is correct and the discrepancies in the current comparisons stem from floating point precision errors and updated code (i.e., the true value was originally computed with an older version of the referenced test problem).

The non-passing tests are located here and here.

I added the following lines to all the files to prevent the output. I do not know enough about logging to know if this is a good solution or not.

# To prevent unexpected outputs in ipython console
logging.getLogger("parso.python.diff").disabled = True
logging.getLogger("parso.cache").disabled = True
logging.getLogger("parso.cache.pickle").disabled = True

More info: ipython/ipython#10946

This should probably be changed to a warning instead of exception. Some optimization methods can breach the limits set to the variables when evaluating, for example, gradients using a central point.

I.e., what is happening here

@gialmisi

Considering checks on line 181 and 192, do you really need the third check?

Initial values are not needed anywhere, so no need to enforce them.

Needs approval from Honda before use.

This will help us enable reading MOPs from a file. We can even try to extend the format ourselves to support simulators and scenarios. If there exists a format with those features already, we can implement that instead.

https://kilthub.cmu.edu/articles/journal_contribution/xMPS_the_extended_MPS_format_for_non-linear_programs/6480236

This seems to be the best place to make that check

Refactor the current DTLZ, ZDT and WFG problem formulations to set an example for future problems.

The so-called CTP problems introduced in https://link.springer.com/chapter/10.1007/3-540-44719-9_20 should be implemented in desdeo-problem.

I think the user should have the option to specify whether they want to maximize or minimize. This can be done in two ways. Either problem.evaluate should return (objectives, constraints, fitness, uncertainity), where fitness = objective value multiplied by +/- one depending on whether to minimize or maximize, OR, the fitness calculation should be done in the optimization methods.

This should also enable us to make visualizations better.