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

fit_mle(Type, y) vs fit_mle(Distribution, y) #1574

Open
dmetivie opened this issue Jun 29, 2022 · 1 comment
Open

fit_mle(Type, y) vs fit_mle(Distribution, y) #1574

dmetivie opened this issue Jun 29, 2022 · 1 comment

Comments

@dmetivie
Copy link

I opened this issue a while ago but was not satisfied with the answer. I tried workarounds but it seems just not right.

Basically, I don't understand the benefits of having 1)fit_mle(Normal, y) work and not 2) fit_mle(Normal(0,1), y). Why not allow both syntaxes?

Sure in case 2) parameters are useless. However, in more complexes mle estimations 1) is limited while 2) is not.
For example, in the package ExpectationMaximization.jl I implemented fit_mle for MixtureModels and for Product distributions.
The fit_mle of product distribution is simply the product of the mle.
Say you have
dist = product_distribution([Normal(1), Exponential(1)]).
Having
fit_mle(typeof(dist), y) does not say which distributions are the elements of the product (Normal, Exponential etc.).
While having fit_mle(dist, y) makes it possible.

Similarly fit_mle(dist::MixtureModel,y) needs the element of the mixture and the type MixtureModel is not enough as an information.
Plus in that case, the actual parameters of dist are not useless since they can be used as starting point of the EM algorithm used to find the mle.

Note that in this package I need (for now) to add

function fit_mle(g::Distribution, args...)
    fit_mle(typeof(g), args...)
end

for my sintaxte to work with Disrtibutions.fit_mle.

@timholy
Copy link
Contributor

timholy commented Jan 13, 2024

Related: when fitting, e.g., MvNormal, sometimes it might be desirable to use shrinkage. Consequently it might be nice to have an interface accepting a CovarianceEstimator.

That said, there are counterarguments:

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

2 participants