No, it's trivial. I'm actually thinking of replacing custom_model_1d with just custom_model. The only substantive difference is in the number of arguments the function takes. Right now we make the distinction because we name the arguments 'x', 'y', etc. which only matters so far as the documentation of the function signature. But we could still use 'x', 'y', 'z' for 1 <= d <= 3 and then just *args for higher-dimensional models should that even be useful to someone.

Same goes, by the way, for the Parametric1DModel and Parametric2DModel classes. I think when @adonath originally worked on these there was a bit more difference between them, but I made the base ParametricModel class more powerful, and as a result there's little to distinguish them except, again, the names and number of arguments to the __call__ methods and I guess the default n_input attribute.

@embray Issue #2274 would probably best be fixed by the generalisations you describe above.

And here's another bug in the current implementation of custom_model_1d (can't handle models with zero parameters) that would probably best be fixed by a rewrite with a generalised custom_model as you describe above:

>>> from astropy.modeling.models import custom_model_1d
>>> def my_model(x):
...     return 42 * x
>>> custom_model_1d(my_model)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/deil/code/astropy2/astropy/modeling/functional_models.py", line 1307, in custom_model_1d
    nparams = len(param_values)
TypeError: object of type 'NoneType' has no len()

Okay, I'll take a look at it. The fix for parameter-less models should be straightforward. I have a slew of other modeling changes in the pipeline that are working toward bashing down unnecessary complexities and distilling the functionality of the core model classes. See #2276 for one of the first in this series, but there are more on the way. It should make issues like this a little easier to deal with.

Since this is a feature request, I'm re-scheduling to 1.0.0

Attached to this a PR to implement a custom_model function as I've promised in the past. So rather than custom_model_2d (or custom_model_1d for that matter) just use custom_model--the number of inputs and parameters is determined by the function syntax.

See the docstring for custom_model for an example of a 2D model.

This may seem frivolous to some, but it's a preview of other related changes to come.

This PR depends on #2580 which should be merged first.

Rebased, hopefully, with doc fixes.

Not sure why the doc build is failing but I don't think it's this PR's fault?

You can read an updated example of using custom_model here: http://embray.github.io/astropy/modeling/new.html#basic-custom-models (this was originally an example for custom_model_1d, just slightly updated with the new semantics).

The API docs for custom_model are rendered here: http://embray.github.io/astropy/api/astropy.modeling.custom_model.html#astropy.modeling.custom_model

@embray - very nice! A few notes from trying this out - not all have to be acted on, but just reporting my experience:

• I was trying to fit a 2-d data and so should have passed 3 arguments to the fit call after the model, but I did:

m = fit(m_init, x, y)

and the error message was:

TypeError: __call__() missing 1 required positional argument: 'y'

which is fine, but maybe it would be nice to get a more explicit error message? (the correct call is shown in the example below)

• The example I ran is:

data = fits.getdata('msx.fits')
data = data[60:80, 70:90]

x = np.arange(data.shape[1])
y = np.arange(data.shape[0])
x, y = np.meshgrid(x, y)

# Define model
@custom_model
def gaussian_2d(x, y, amplitude=1., mu_x=10, mu_y=10, sigma=1):
    return amplitude * np.exp(-0.5 * ((x - mu_x) / sigma)**2) * np.exp(-0.5 * ((y - mu_y) / sigma)**2)

m_init = gaussian_2d()
fit = LevMarLSQFitter()
m = fit(m_init, x, y, data)

when I did this, I got the warning:

WARNING: The fit may be unsuccessful; check fit_info['message'] for more information. [astropy.modeling.fitting]

but as a user, I don't know what fit_info is. Could this be made more explicit? (It turns out the fit does actually look good).

Other than that, this works great, so 👍 from me! The issues above may be unrelated to this pull request, and just more general comments.

@astrofrog Those are issues in the fitter--totally unrelated to the custom_model implementation. I'm reworking fitters too but it's lower priority right now.

@astrofrog Or are you saying something in the sample documentation needs to be fixed too?

@embray - if it's unrelated to this PR then ignore for now. Should I open issues for those or will they become moot once you rework the fitters anyway?

You can open an issue if you want.

Not sure why I didn't merge this already, but now it needs to be rebased..

Rebased. Waiting on Travis...

Docs build failed due to #2914 , but I confirmed locally that the docs built without warning (and prior the rebase the build passed) so I'm going ahead and merging.