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

Improvements to stats stopping criteria verification #77

Open
abelsiqueira opened this issue Oct 2, 2023 · 4 comments
Open

Improvements to stats stopping criteria verification #77

abelsiqueira opened this issue Oct 2, 2023 · 4 comments

Comments

@abelsiqueira
Copy link
Member

The way that it set_status! and get_status work right now is too verbose.
You have to pass max_eval, max_iter and max_time every time. Probably these should be stored as part of the stats, or as a separate object - this would have to be internal to stats to avoid allocation.

The done = stats.status != :unknown is prone to error. A function check on stats would be better.

@tmigot
Copy link
Member

tmigot commented Oct 23, 2023

Ok, so if I follow your idea:

  • we would store a boolean value for each status in the stats,
  • and, have a function
check_status(stats) = stats.status != :unknown

@abelsiqueira
Copy link
Member Author

I am not sure yet. Maybe something like Stopping with no internal computations would make sense?
I just feel like iter and elapsed_time are already being stored inside stats, so maybe it would make sense to have something as part of stats that check for stopping condition. But anyway, very open ended from my part.

The second, yes, I think a stop_criteria_satisfied(stats), for instance, would make the while look nice: while !stop_criteria_satisfied(stats), etc.

@dpo
Copy link
Member

dpo commented Oct 29, 2023

I'm not a big fan of that because it hard-codes stopping criteria. We developed the callback mechanism to provide much more freedom in that respect.

@abelsiqueira
Copy link
Member Author

It doesn't prevent using other stopping criteria nor the callback. Also, these are the criteria that we want in our solvers (already being used). Why is it hardcoded?

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