Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We should have min/max target estimates of problems #58

Closed
nojhan opened this issue Sep 17, 2020 · 5 comments
Closed

We should have min/max target estimates of problems #58

nojhan opened this issue Sep 17, 2020 · 5 comments

Comments

@nojhan
Copy link
Contributor

nojhan commented Sep 17, 2020

On a separate accessors than optimum.

@nojhan
Copy link
Contributor Author

nojhan commented Sep 18, 2020

This would be useful to automatically derivate ECDF logger's target bounds for a problem/suite.
If the information is not available, then accessors would raise an error and the user would defaults to hand-picked bounds.

Then additional simple constructors would be interesting, like:

IOHprofiler_ECDF_logger(IOHprofiler_Problem& pb, double max_evals, size_t buckets);
// derivates target bounds from pb and use square domain.

@nojhan
Copy link
Contributor Author

nojhan commented Apr 12, 2021

Is it closed because it's done or close because it will not be added?

@wangronin
Copy link
Contributor

I think because is it done (not super sure..)

@jacobdenobel did you incorporate this one in the new code structure? I don' recall anything..

@jacobdenobel
Copy link
Contributor

jacobdenobel commented Apr 12, 2021

This was closed because #54 was merged, in a comment there it was mentioned that this also included a feat for fixing this issue.

This is sligthly modified in the restructured version, and there is no seperate accessor for has_opt, but you can infer this information like so: !problem.objective().y.empty(). I think this settles this issue. If not, please let me know.

@nojhan
Copy link
Contributor Author

nojhan commented Apr 12, 2021

Thanks! (and always put a comment when closing issues, that way I will not bother you anymore ;-)

jdreo added a commit to jdreo/IOHexperimenter that referenced this issue Feb 1, 2022
This checks whether the optimum has been set or not.
This is useful for automated filtering of problems with known optimum and allows to avoid a very long test.

This brings back the (lost?) `empty` method mentionned in issue IOHprofiler#58.
jdreo added a commit to jdreo/IOHexperimenter that referenced this issue Feb 1, 2022
This checks whether the optimum has been set or not.
This is useful for automated filtering of problems with known optimum and allows to avoid a very long test.

This brings back the (lost?) `empty` method mentionned in issue IOHprofiler#58.
jdreo added a commit to jdreo/IOHexperimenter that referenced this issue Feb 1, 2022
This checks whether the optimum has been set or not.
This is useful for automated filtering of problems with known optimum and allows to avoid a very long test.

This brings back the (lost?) `empty` method mentionned in issue IOHprofiler#58.
jdreo added a commit to jdreo/IOHexperimenter that referenced this issue Apr 11, 2022
This checks whether the optimum has been set or not.
This is useful for automated filtering of problems with known optimum and allows to avoid a very long test.

This brings back the (lost?) `empty` method mentionned in issue IOHprofiler#58.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants