You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the current behavior?
Currently, many parts of the code base assume that problems have ideals and nadirs defined. However, in practice we often cannot be sure that we actually know them. Especially nadirs are difficult in this regard. This uncertainty in combination with immutability of problem definitions causes some practical problems, because we might later learn of non-dominated decision alternatives that are worse in some objective than our presumed nadirs.
Describe the solution you'd like
When talking about api and database specifically, it might make sense to store the best estimates of ideals and nadirs somewhere and use those, if the problem definition does not contain any. This would require updates in many mcdm methods and scalarization functions to have them optionally take ideals and nadirs as function parameters.
The text was updated successfully, but these errors were encountered:
Currently, this is mostly an issue with functions that add scalarization functions to problems. The functions that add scalarizations should accept (estimates of) an ideal and nadir point as optional arguments. If one of these is not given, then the functions should try to read them from the problem. If the problem does not have one or the other, or both, then ac exception should be raised.
When it comes to the database, indeed, these should be handled there.
What is the current behavior?
Currently, many parts of the code base assume that problems have ideals and nadirs defined. However, in practice we often cannot be sure that we actually know them. Especially nadirs are difficult in this regard. This uncertainty in combination with immutability of problem definitions causes some practical problems, because we might later learn of non-dominated decision alternatives that are worse in some objective than our presumed nadirs.
Describe the solution you'd like
When talking about api and database specifically, it might make sense to store the best estimates of ideals and nadirs somewhere and use those, if the problem definition does not contain any. This would require updates in many mcdm methods and scalarization functions to have them optionally take ideals and nadirs as function parameters.
The text was updated successfully, but these errors were encountered: