Comments you submit will be routed for moderation. If you have an account, please log in first.

Ticket #4224 (assigned enhancement)

Opened 10 years ago

Last modified 8 years ago

Create InverterApplication to reformulate maximization problems

Reported by: jdsiiro Owned by: jdsiiro
Priority: major Milestone: Acro 2.x
Component: Colin Version:
Keywords: Cc:
Subcomponent: Source Code


We need a convenient InverterApplication<ProblemT> that can take a maximization problem and convert it to a minimization problem for solvers that cannot handle maximization problems.


Change History

comment:1 Changed 10 years ago by wehart

  • Owner changed from wehart to jdsiiro
  • Status changed from new to assigned

I've created an InvertSenseApplication?, but I have several issues with this design:

  1. I think this should be generalized to specify the sense (e.g. a DefinedSenseApplication?). For multiobjective applications, we may have objectives with difference senses, but for a weighted objective we need to combine them as a min or max problem. Thus, we need to 'define' the sense for a MO application, not invert it.
  1. How will this application be applied? This isn't going to be automatically applied, as most other reformulation applications would be. From a user's point of view, you'd like to do something like:


But that has problems for two reasons:

  1. there already is a set_sense method, which is only exposed for configurable applications, and
  1. if this is an application method, we need to somehow initialize the problem with the new application! That would lead to a syntax like:

problem = problem->set_sense(colin:minimize);


I see several possibilities for setting up the DefinedSenseApplication?

  1. Overload the new_application() method:

problem->set_application( new_application(problem, sense) )

  1. Create a new method for problem objects:




  1. Helper function


I don't really like any of these options. Consider the following alternative: let the OptSolver_Base class define the sense of the _optimizer_. In the set_problem method, if the sense does not match, then it sets up this reformulation automatically. In this case, we could manage the construction of the reformulation in any way we like, since we're hiding that detail from the user... The only complication is for MO problems, where we need to interrogate the senses of all dimensions to see if a reformulation is necessary.

I personally think this last option is the best choice. By renamining minimize() to optimize(), we're forcing _all_ COLIN solvers to perform a check of the problem sense, and perhaps setup an inverted application. This last option automates that process for the solver developer.

I'm assigning this ticket to John to make sure that he weighs in on this design question.

comment:2 Changed 9 years ago by wehart

  • Milestone changed from Colin 3.0 to Colin 3.1

Deferred to COLIN 3.1

comment:3 Changed 8 years ago by jdsiiro

  • Milestone changed from Colin 3.1 to acro-dakota 2.0

comment:4 Changed 8 years ago by jdsiiro

  • Milestone changed from acro-dakota 2.0 to Acro 2.x

Important, but not critical for Acro/DAKOTA integration.


Add a comment

Modify Ticket

Change Properties
<Author field>
as assigned

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.