Open nikohansen opened 8 years ago
I agree with the proposal as discussed already at GECCO-2016 and in particular on the number of added functions.
Does it mean that the data from this year will be abandoned?
On Sun, Aug 7, 2016 at 9:05 PM, Dimo Brockhoff notifications@github.com wrote:
I agree with the proposal as discussed already at GECCO-2016 and in particular on the number of added functions.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/numbbo/coco/issues/1118#issuecomment-238101591, or mute the thread https://github.com/notifications/unsubscribe-auth/ADoe-3mRn8l5gz7nD_W7MKly6ORCc2ZEks5qdixcgaJpZM4JVO5Z .
Does it mean that the data from this year will be abandoned?
No, of course not.
I started to implement the extended bbob-biobj
suite (called bbob-biobj-ext
for now) based on the feature-refalg
branch. The C code is running (tests run through in the CI) and I also tested already that we can keep the first 10 instances (i.e. the checks, that the instances produce an actual 2-objective problem, run through). Missing are still the following points:
I have been again a bit too optimistic wrt the CI tests :-( : on one Windows machine and the Mac, the tests do not yet run through:
[...]
..f65..........f66..........f67..........f68..........f69..........f70..........f71......
....f72..........f73..........f74..........f75..........f76..........f77..........f78....
......f79.Assertion failed: ((nadir[i] - ideal[i]) > mo_discretization), function
mo_normalize, file code-experiments/src/mo_utilities.c, line 54.
Build step 'Execute shell' marked build as failure
Remark: a closer look revealed that the second objective of f79 is the Weierstrass function for which seemingly no nadir_value
is available---probably because the optimum is not unique (the nadir_value is actually nan
for this function, not clear why it did not crash on my computer already before).
Update: the nan
did not cause an error on my computer, because it is not defined outside COCO and thus defined through COCO as 8.888800e+088
. After discussing with @nikohansen, we decided to simply take out the Weierstrass function out of the bbob-biobj
extsuite since it's
best_parametervector is not unique and thus, a nadir point not easily computable within COCO. The updated
bbob-biobj-ext` suite with 92 functions is now available in my fork and the tests run through on all CI slaves.
In order to keep the repository small, we need to put the (new and old) files of the regression test somewhere else (the new bbob-biobj-ext
files are about 60MB large). The discussion of Jan 12, 2017 suggested that we keep them in the coco GForge svn repository and in addition provide them like any other data file on the GForge server from where they are downloaded if the test itself does not see them locally.
Updated list of things to do (possibly done already at the time of writing, to be checked):
bbob-biobj
suite (e.g. with the data from the 2017 algorithm of Simon)bbob-biobj
suite - like that, we need to touch less algorithm data sets when updating.dat
file)See also #1873.
Add-on: we should implement the functionality that the order of the objective functions is changed pseudo-randomly with the instance number. The reason is that in the original bbob-biobj
suite, the first objective function never has a larger function index than the second objective function, resulting in the first objective being easier than the second one in more cases than the opposite.
I guess the closing of this issue was a mistake. Most issues above are still not addressed.
We should consider to proposed extended versions of the
bbob
andbbob-biobj
test suites.Proposal for
bbob-biobj
: we add all within-group combinations ofbbob
functions which are not already inbbob-biobj
and which do not combine a function with itself. This will add4*(4+3+2+1-1) + 3+2+1-1 = 4*9+5=41
functions.Rationale: this will add more diversity w.r.t. the used single objective functions (as suggested by @loshchil) and more functions where both objectives are from a similar "function domain" (as suggested by @Ulfgard).