lexicographic (hierachical) multi-objective optimization

[jeffreyhanson]

lexicographic (hierachical) multi-objective optimization

[ricschuster]

I like this idea Jeff!

Personally, I like the first approach of adding a parameter. Maybe instead of blended we could add hierarchical and set it to FALSE by default?

This way current code would still work as the behavior wouldn't change. At least I think so. Would it break existing code to add another parameter like this?

I don't think users would be too confused as long as the documentation explains things well. Maybe I'm off though. Would be great to get some feedback from users on this too.

[jeffreyhanson]

Yeah, I agree the first approach has its benefits. For example, (1) we don't need to introduce a new family of functions, (2) we don't need to update the print() method for problem() objects to accomodate a new family of functions, (3) it provides an easy way for users to play around with hierachical optimization, and (4) it reduces the conceptual load/burden for using the package (e.g., users don't have to learn about "penalties" vs. "${something else}" for blended vs. hierachical optimization, and instead users only need to think about "penalties" and if they should be optimized using blended vs. hierachical approaches).

One other thing to think about is that we might want to also add a parameter to allow the optimization process to degrade the primary/main objective by a relative amount. E.g., you might havbe a main objective of minimizing cost and a secondary objective of minimizing boundary length. In some cases, you might not want to accept any degradation (meaning that you want to reduce boundary length as much as possible, but don't make it any more costly). In other cases, you might want to accept a small amount of degredation (meaning that you want to reduce boundary length as much as possible, and you're happy for the cost to increase slightly [e.g. 5%]). So, if we wanted to add this, we would need to add an extra parameter too - so I don't know if/how that would influence our choice of API?

[ricschuster]

Great points!

Interesting idea about the additional parameter. I think that's a good idea and I don't think it influences the choice of API at least for me.

What about you?

[jeffreyhanson]

Yeah, I worry that such a function could be confusing, because some parameters would only have an effect when other parameters are NULL or TRUE/FALSE. E.g., at the moment we have this as a function definition

add_boundary_penalties(
  x,
  penalty, 
  edge_factor = rep(0.5, number_of_zones(x), 
  zones = diag(number_of_zones(x)), 
  data = NULL
)

This would turn into something like (where reltol and hierachical are new parameters for hierachical optimization). Note that zones and daa parameters are always last for consistency with other functions in prioritizr.

add_boundary_penalties(
  x,
  penalty, 
  edge_factor = rep(0.5, number_of_zones(x), 
  reltol = NULL,
  hierachical = FALSE,
  zones = diag(number_of_zones(x)), 
  data = NULL,
)

So, to use blended optimization, it would be the same as usual, e.g.:

p %>% add_boundary_penalties(penalty = 0.001)

And for hierachical optimization, it would be something like this:

p %>% add_boundary_penalties(penalty = NULL, reltol = 0.05, hierachicial = TRUE)

If we had the hierachical stuff in a different family of functions, then it would look something like this instead:

# blended
p %>% add_boundary_b_penalties(penalty = 0.001)

# hierachical
p %>% add_boundary_h_penalties(reltol = 0.05)

However, I'm not 100% happy with _h_ and _b_ penalty types, because add_asym_connectivity_penalties() is already long enough, and I would prefer not to make this function name even longer.

[ricschuster]

Hmmm, the way you describe things here makes me reconsider my initial preference. Given the potential for confusion of the approach to keep the functions and adding parameters, I am now favoring the _h_ and _b_ approach.

Its still hard to say how much appetite for the _h_ functions is out there though. I have no idea about that one.