-
Notifications
You must be signed in to change notification settings - Fork 0
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
Stan's machine-readable return types (as opposed to its free-form messages) conflict. #125
Comments
Comment by ariddell Good catch. My sense was that errors are typically communicated with exceptions. Having to think about exceptions and error-indicating return codes (rather than just one of the two) seems like a unnecessary burden on the developer. |
Comment by ariddell We probably all agree that they (error messages/codes) should at least not conflict/overlap without ample documentation. Is unconflicting them a discrete task? If we've got most error information being communicated with exceptions, it seems reasonable to default to communicating error information that way. |
Comment by sakrejda @bgoodri @syclik I think Ben's comment is more relevant for this issue than the dther one so I'm adding it here. It looks like we only use one of the error codes and (maybe?) throw for some of the other conditions. The implementation of L-BFGS by Jorge Nocedal has documented codes that it would be useful to stick to. They are documented in the package distributed at: http://users.iems.northwestern.edu/~nocedal/lbfgs.html From code at that link:
|
Comment by sakrejda @ariddell The coding would be straightforward so I made it an issue rather than trying to discuss on the board. My suggestion is:
|
Comment by ariddell Sounds good to me. I like the idea of being consistent: if we are communicating information via exceptions when NUTS or VB errors occur, we should do the same thing with optimizing. |
Comment by bob-carpenter The utility of any warning message or return code is what the client From a C++ perspective, all those functions with return codes
But, if we do that, then clients like CmdStan would have to catch We can use it to figure out what kinds of warning conditions and error
|
Issue by sakrejda
Friday Dec 30, 2016 at 19:31 GMT
Originally opened as stan-dev/stan#2198
Summary:
Stan defines machine-readable return types (error codes, exceptions, ....??) in a variety of places and they don't necessarily agree.
Description:
Expected Output:
Writing a suggestion below but I'd be fine with a variety of solutions. We could just always return 0 and throw on all clear errors. Figuring out if the output is good enough to use is a little more advanced than typical error codes should be used to classify.
Current Version:
v2.14.0
The text was updated successfully, but these errors were encountered: