-
Notifications
You must be signed in to change notification settings - Fork 37
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
Estimator's error bars #54
Comments
Personally my feeling is that if the "error bars" are going to be in the abstract interface, then returning some arbitrary confidence interval is the strongest trade-off between statistical approximations, not constraining implementations, and allowing users to do some very basic statistics on the output in the abstract. The absolute most basic Detailed statistics can be returned separately as an implementation detail, and given how specialised these would be per implementation, it's not clear to me that anything would be bought by trying to abstract that component (just as the RFC doesn't). I don't feel strongly about this. My vote would go to returning the 16-84 confidence interval ( |
Reporting a confidence interval is about the closest thing we can get to allowing a user to ask for an "error bar" without making assumptions about the underlying statistics. So, I agree with Jake here that the interface should be explicit about returning an interval. The 1σ interval also makes sense as a default (a 68% confidence interval). |
A derived discussion of #51 about
Estimator
's representation of error bars:For reference, see:
With the aim to extracting that conversation from the RFC on the details on the how (having agreed on the spirit of the need for some for of error represetation in
TaskResult
), please continue the discussion in this issue.This discussion might result in one of the following out comes:
The text was updated successfully, but these errors were encountered: