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

Warnings and Results #1

Open
nrlucaroni opened this issue Oct 10, 2013 · 3 comments
Open

Warnings and Results #1

nrlucaroni opened this issue Oct 10, 2013 · 3 comments

Comments

@nrlucaroni
Copy link
Member

I would like to use Result.t in Core to notify a user about issues during the analysis. Yet, some issues may be acceptable and should also return a result --hitting the maximum number of iterations or a large slope in the optimization procedure both return acceptable results but in certain situations should be looked at further for numerical and stability issues.

The Result.t module does not cover warnings. Should Result module be re-implemented to a triple of type,
('ok,'warn,'err) t = | Ok of 'ok | Warning of 'ok * 'warn | Error of 'err
or is there a module that can take care of these issues?

Sure, 'err types could contain the correct value, but it's an abuse of the intent of the module --- since it's not an error state. Also, what happens when these issues are returned in the 'line-search' function used by the BFGS? This flow of errors through a computation (Monad) would apply to combinatorial optimization procedures extensively as well, since my hope is that they are implemented in a way such that they can be composed easily.

@xandkar
Copy link

xandkar commented Oct 14, 2013

Forgive me for butting-in without understanding the context, but this seems a general-enough of an issue:

Did the computation manage to compute a value?

A) Yes. Then status is "Ok". And attached is a pair of 1) computed value; 2) a measure of quality of the computed value (or any warning, etc.) which can be used by the caller to determine whether to continue with the value.
B) No. Then status is "Error" and attached is the reason for failure.

To me, this model has pretty clear semantics, whereas a dedicated "Warning" status is ambiguous - "Was a value computed? If yes, can I use that value? If so, then why is the status not Ok? If not, then why not an Error?".

@nrlucaroni
Copy link
Member Author

Thanks, I absolutely appreciate it. I was conflicted if an additional state would be necessary. I'll go with this recommendation.

@xandkar
Copy link

xandkar commented Oct 15, 2013

Coolio. I usually obsess over these sort of decisions as well :)

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

2 participants