-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Delete package? #6
Comments
Just the DiffEqJump stuff uses it, and yeah one of the main purposes was to not have the binaries that Distributions.jl pulls in. |
Fair enough. It just felt to me like the README
suggests that the implementation in this package is somewhat superior and faster than the one in Distributions. That's actually not the case, and if you call |
it used to be better 🤷♂ . |
It still is better overall for simple I get 10% improvement in a large simulation using |
To get up to the same speed, you have to use the samplers in Distributions and should not run |
Ok I see you're right, they have basically identical performance and no allocations. Distributions should swap the code comments for real documenation, those types are pretty much impossible to find or understand currently. |
In the following benchmarks the samplers in Distributions are as fast as the implementations in this package:
I get
and
Actually, performing the benchmarks of
n_count
andn_ad
with integer values forλ
(as done in the README) leads to subpar performance compared with Distributions. Forn_count
this is probably due to the comparison of integer and float values in https://github.com/JuliaDiffEq/PoissonRandom.jl/blob/master/src/PoissonRandom.jl#L11, as@code_typed
indicates:Hence, should we deprecate this package by adding a deprecation warning to
pois_rand
? How many DiffEq packages depend on PoissonRandom? Would it be sufficient to implementpois_rand
(if we want to keep it) in DiffEqJump using the samplers in Distributions?The text was updated successfully, but these errors were encountered: