You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, stopping criteria are defined during the implementation of the solver. However, sometimes it might be useful if users could add their own stopping criteria. This would require a complete redesign of how termination works. One of the key aspects of termination is that it needs access to the fields of the solver which makes it difficult to implement in a generic way. However, similar to how observers work, the needed variables could be stored in a key-value store and passed to the user-defined termination function. It needs to be evaluated how efficient such an approach would be.
The text was updated successfully, but these errors were encountered:
We've had success with writing our own execution loop based on the code in Executor.run(). This gives us more fine-grained control over termination criteria. This approach is similar to the api for libgsl. Perhaps eliminating the Executor and allowing the user to write the loop would achieve this customizability.
I was planning to approach this the same way as it is done for observers. A list of (user-defined) stopping criteria (defined by a trait) can be attached to an Executor, which will all be evaluated in each iteration. A stopping criteria has access to the current state (and maybe the key-value metrics which are passed to the observers). The question remains how to get access to the fields of the solver, but maybe this isn't really needed.
These stopping criteria would be in addition to the stopping criteria implemented in the respective solver.
Currently, stopping criteria are defined during the implementation of the solver. However, sometimes it might be useful if users could add their own stopping criteria. This would require a complete redesign of how termination works. One of the key aspects of termination is that it needs access to the fields of the solver which makes it difficult to implement in a generic way. However, similar to how observers work, the needed variables could be stored in a key-value store and passed to the user-defined termination function. It needs to be evaluated how efficient such an approach would be.
The text was updated successfully, but these errors were encountered: