Cosmo : not accept array-like, only array?

[nstarman]

Description

Many of the functions in astropy.cosmology accept any array-like input and have to perform a check to distinguish between scalars and arrays. While this is faster than just passing everything through np.array()
(as discussed in #12145 (comment)), the check is still a performance bottleneck.
It seems to me that there is not much added value in Cosmology functions accepting any array-like input rather than actual ndarrays.
I propose limiting the accepted input types to numbers.Number (e.g. int, float) and numpy.ndarray (includes Quantity) and eliminating array-like inputs, like lists and tuples.

Looking forward, this is part of a longer plan to "vectorize" Cosmology, both the methods (like with #11893), but also have the entire class work with arrays of parameters, not only scalar values. With only Number and ndarray (incl. Quantity) as valid inputs it will eventually be possible to eliminate workaround methods like astropy.cosmology.utils.vectorize_if_needed which are likewise performance bottlenecks. Also at some point I would like to extend the c backend, hopefully with mypyc so everything can be written in python and transpiled to performant c, and simple type inputs make for much easier / better code.

I would appreciate some second opinions as this is a non-backward compatible change. I think / hope its a painless one, especially since most people just use numpy arrays anyway, but it's still a change. v5.0 seems the right time, if any.

tag: @mhvk @adrn @aconley

astropy/astropy/cosmology/flrw.py

Lines 417 to 419 in 23404ee

	if isiterable(z):
	z = np.asarray(z)
	return self._Om0 * (1. + z) ** 3 * self.inv_efunc(z) ** 2

Checks like the above will not be necessary.

[mhvk]

I generally agree with anything that sets expectations for when things work (numbers, ndarray, Quantity here), and doesn't try to test on input and coerce - rather just duck type for things that do not fall in the list of accepted items (e.g., a dask array may well work, but let it be up to that class to be sufficiently close to ndarray). In your example, I would indeed think that one should just be able to directly do the calculation. (Actually, in that particular example, it would seem true even now that whatever is done is done in inv_efunc...)

[aconley]

Seems reasonable to me. The thing I cared about -- back when I was an astronomer -- was having scalars and ndarrays. As long as you can keep those, lists are not that interesting. But in principle that requires a major version bump in astropy, which is not something that happens so frequently.

…

On Mon, Sep 13, 2021 at 2:40 PM Marten van Kerkwijk < ***@***.***> wrote: I generally agree with anything that sets expectations for when things work (numbers, ndarray, Quantity here), and doesn't try to test on input and coerce - rather just duck type for things that do not fall in the list of accepted items (e.g., a dask array *may* well work, but let it be up to that class to be sufficiently close to ndarray). In your example, I would indeed think that one should just be able to directly do the calculation. (Actually, in that particular example, it would seem true even now that whatever is done is done in inv_efunc...) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12166 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPLNBQKQ2ANUDPHKEOIQDTUBZOTFANCNFSM5D6SCAOQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[nstarman]

@mhvk @aconley. Thanks for the input! (and for agreeing with me 😆).
I have a PR ready, but I'll wait until #12145 is in, as that closes a related bug.