Usage of an archive with and without constraints and two objectives

[nikohansen]

import moarchiving as moa

a = moa.get_mo_archive(n_obj=2)
a2 = moa.get_cmo_archive(n_obj=2)
a.add([1, 1])
a2.add([1, 1], [3,4,5])
print(type(a), type(a2))
print(a, a2)
print(list(a), list(a2))
len(a), len(a2)

<class 'moarchiving.moarchiving.BiobjectiveNondominatedSortedList'> <class 'moarchiving.constrained_moarchive.CMOArchive'>
[[1, 1]] <moarchiving.constrained_moarchive.CMOArchive object at 0x120cc5670>
[[1, 1]] []
(1, 0)

Questions:

• How can I see the elements of a2?
• Is the different behavior of list(.) or len(.) to be expected (by a user) or necessary? It doesn't seem desirable?

[naceee]

You are using the constrained archive in the correct way, but the elements with constraint violation > 0 are pruned away (but the lowest sum of cv is remembered for the indicator calculation, the same way as with hv+).

If this is the right approach I don't know (I thought we talked about this, but maybe it was just me and @ttusar ?)

[nikohansen]

OK, if I do

a2.add([1, 1,], [-5.2, 3.0])

I get

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[21], [line 6](vscode-notebook-cell:?execution_count=21&line=6)
      [4](vscode-notebook-cell:?execution_count=21&line=4) a2 = moa.get_cmo_archive(n_obj=2)
      [5](vscode-notebook-cell:?execution_count=21&line=5) a.add([1, 1])
----> [6](vscode-notebook-cell:?execution_count=21&line=6) a2.add([1, 1,], [-5.2, 3.2])
      [7](vscode-notebook-cell:?execution_count=21&line=7) print(type(a), type(a2))
      [8](vscode-notebook-cell:?execution_count=21&line=8) print(a, a2)

File ~/git/moarchiving/moarchiving/constrained_moarchive.py:101, in CMOArchive.add(self, f_vals, g_vals, info)
     ~/git/moarchiving/moarchiving/constrained_moarchive.py:99)     return
     ~/git/moarchiving/moarchiving/constrained_moarchive.py:100) self.archive.add(f_vals, info)
-->  ~/git/moarchiving/moarchiving/constrained_moarchive.py:101) self._hypervolume_plus_constr = max(self.archive._hypervolume_plus, -self.tau)

TypeError: '>' not supported between instances of 'int' and 'NoneType'

which also suggests a lack of test coverage?

[naceee]

Hm, I missed that one, let me take a look.

[naceee]

The desired functionality is that if any constraint is violated, the point should be pruned right? Having negative values then really messes up the indicator computation, that is based on the sum of constraints...

Maybe the way to deal with this is to change all the negative values to 0?

[nikohansen]

I am not aware of your specific requirements, but I don't think the passed constraint values should be changed, they should be stored as is. However, the penalty computation should always take max(0, constraint_value), because all negative values are equally feasible.

[naceee]

I fixed this and added some more tests. The bigger issue was that the self._hypervolume_plus_constr was trying to be updated when the reference_point was not given at the start.

Should I create a new pull request now?

[nikohansen]

The desired functionality is that if any constraint is violated, the point should be pruned right?

I am confused, because in this case we would not need to compute the penalty or store any positive constraint values. I assume g > 0 is a violation, hence max(0, g) is always zero for a feasible solution, I guess I am missing something?

Second confusion: the code seems to add some negative penalty for a constraint violation to _hypervolume_plus_constr, but at first sight I don't see that it takes the penalty back when the violating point becomes dominated and removed from the archive?

[naceee]

I'm not sure I understand your questions, but I hope this clears things:

A point that has any positive constraint values is unfeasible and is not added to the archive. But we still update the indicator for constrained problems called _hypervolume_plus_constr.

By definition _hypervolume_plus_constr (= ICMOP) is equal to the total constraint violation + tau where tau is some user defined constant, when no feasible solution has been found so far. When a feasible solution is found the indicator value is defined to be min(tau, hypervolue_plus). I think this is the reference paper (in the implementation we multiply the formulas with -1, to have all the indicators consistent).

[nikohansen]

is equal to the total constraint violation

I can't see why this makes sense though. It seems to have no reasonable invariance in the number of infeasible points and tends to diverge when we don't find a feasible point. Shouldn't one want to measure the minimal constraints violation observed?