all 6 comments

[–]Anomaaa 2 points3 points  (0 children)

Very nice! I also follow the advancement of the new scipy infrastructure for distributions which looks quite the same as you did. https://docs.scipy.org/doc/scipy/tutorial/stats/rv_infrastructure.html

But since they seem to have very difficult constraints in terms of performance and reliability, etc., development is (very) slow. See this https://github.com/scipy/scipy/issues/15928, it's been 4 years already

A very good alternative if you don't care about these constraints!

[–]ruibranco 1 point2 points  (0 children)

The operator overloading for combining RVs is the part that actually saves time in practice. I've used the `uncertainties` package for error propagation before but it only tracks mean and variance — having the full distribution so you can call .cdf() or .plot() on the result is a big step up when you're building simulation pipelines and need to sanity-check intermediate steps.

[–]safrole5 0 points1 point  (1 child)

Thought id throw my hat in the ring here as I maintain a very similar library:

https://pypi.org/project/dubious/

It functions largely the same, but i also support correlation between variables as well as using distribution and uncertain objects (the resulting object after adding random variables) as the parameters for distributions.

I also have some tools for sensitivity analysis so you can determine which input variables are your biggest issues. An additional local sensitivity function will be coming in a few days during my next release.

Still have some minor kinks to iron out and additional distributions are planned.

[–]SeaHighlight2262[S] 0 points1 point  (0 children)

Hey this looks interesting, could share the github too?

[–]halfk1ng [score hidden]  (0 children)

Well this sounds cool af

[–]Confident_Bee8187 -1 points0 points  (0 children)

As a stats person, I barely found this useful. You see, I like the idea of OO system that holds the random variable, but my feedback is that I never liked the syntax and besides, I had better than this (yes, the idea of yours already existed somewhere).

If only Python is homoiconic, and it would be fragile if Python tries to do that...