Add Poisson likelihood fitter

[cdeil]

I would like to add a PoissonLikelihoodFitter as available e.g. in Sherpa (described here) to be able to fit Poisson count data.

A preliminary version can be found here: class, example.

TODO:

• Make it work with n-dimensional models and data (currently only supports 1-dimensional)
• Pass extra arguments along to scipy.optimize.minimize.
• Is this the right way to handle integral models?

cc @nden, @embray Should I try to implement this now and get it into astropy or should I wait for your modeling APE and further structural changes in astropy.modeling?

EDIT: the issue description was updated, so some comments below are outdated / irrelevant now.

[eteq]

I don't know if we ever fully specified a version. It's already an "optional" dependency, so using whatever version makes sense is fine.

Probably the best thing to do is a try/except inside the function that explicitly states something like "Scipy 0.11 is needed for custom fit functions"

[cdeil]

Here's a first prototype version: http://nbviewer.ipython.org/7062154
that I managed to write thanks to @nden's example here: https://gist.github.com/nden/5466946

@nden At the moment to create a user-defined fitter one has to add to the constraintsdef dict (or the Fitter initialisation will fail in the _constraintscheck):

from astropy.modeling.fitting import constraintsdef
constraintsdef['CashFitter'] = ['fixed']

I guess this shouldn't be needed?
If it is, it should be described here.

[embray]

Nice. I do think there are some areas where defining a new fitter could be easier. I have a note somewhere, for example, that the constraintsdef dict shouldn't be used explicitly anywhere, and that the purpose it serves could be handled automatically by a Fitter metaclass and a couple class attributes. We'll see if I get to that. Defining the errorfunc could be a bit easier too. But overall it looks like that was pretty easy.

[cdeil]

+1 to removing the global constraintsdef dict and storing this info in classes.

[embray]

Done in 3552d36

[astrofrog]

+1 to the idea, but removing 1.0 milestone

[cdeil]

We're using Sherpa now, so we don't need this in Astropy any more and I don't plan to work on it there.
Closing this old issue.

[embray]

Would rather leave issues like this open--just because you don't need it or plan on working on it for Astropy doesn't mean it's not a good issue to keep open.

[cdeil]

An issue is mainly useful if there's a chance that it leads to improvements, right?

If it's just a bunch of year-old and outdated discussion keeping it open and making people re-read through it is just annoying.

In this case if someone is interested to implement this in astropy.modeling, they should ignore the discussion here and continue with #3786 .