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

Asymmetric errors #69

Open
BeastyBlacksmith opened this issue Mar 31, 2020 · 5 comments
Open

Asymmetric errors #69

BeastyBlacksmith opened this issue Mar 31, 2020 · 5 comments

Comments

@BeastyBlacksmith
Copy link
Contributor

Are you planning to support asymmetric errors like 2.0 + 0.1 - 0.05?

@giordano
Copy link
Member

giordano commented Apr 4, 2020

To be honest, I've never got how this works within the linear error propagation framework, which this package uses. Is the propagation rule the same as with symmetric errors, but using different sigmas on each side? Do symmetric errors break the assumption that errors are normally distributed?

@BeastyBlacksmith
Copy link
Contributor Author

You are right, it does. Seems like MC is the way to go then.
I found this paper: https://iopscience.iop.org/article/10.1088/1681-7575/ab2a8d/pdf

@giordano
Copy link
Member

giordano commented Apr 5, 2020

Yeah, this looks more something for MonteCarloMeasurements.jl than this package.

@derikk
Copy link

derikk commented Nov 13, 2020

The Particle Data Group Review uses asymmetric errors for many of its consensus particle data values (e.g. quark masses). These are in turn used by packages like Corpuscles.jl, which currently implements its own MeasuredValue struct and methods. This works in some cases, but requires code duplication, and doesn't play nicely with other packages.

Using MonteCarloMeasurements.jl for that package would be too heavy-handed, and it's not clear how that would be done without knowing the underlying distribution that the uncertainties come from.

It would be reasonable to expect functions like stdscore to error for measurements with asymmetric uncertainties, where the assumption of normality breaks down.

@derikk
Copy link

derikk commented Nov 13, 2020

On the other hand, given that so much of this package's structure assumes normally distributed errors, perhaps it's best not to make such a big change.

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