Maintining ufunc compatibility

[msyriac]

I've started playing around with enlib and love how it inherits from numpy. But sometimes, the enlib-ness of a map gets stripped away when I pass it to a ufunc. For example:

>>> type(fAlpha)
<class 'enlib.enmap.ndmap'>
>>> retMap = np.fft.ifftshift(enmap.ifft(fAlpha).real)
>>> type(retMap)
<type 'numpy.ndarray'>

How can we prevent this? My workaround right now is to do something like:

retMap = np.fft.ifftshift(enmap.ifft(fAlpha).real)+fAlpha*0.

to allow it to retain its wcs.

[amaurea]

Yes, I agree that that would be nice. I have a function for giving back the wcs, but it's not very convenient:

retMap = enmap.samewcs(np.fft.ifftshift(enmap.ifft(fAlpha).real), fAlpha)

This isn't necessary for all functions. For example np.sum works fine and preserves the subclass. The problem is functions that clobber the subclass, for example by using np.asarray instead of np.asanyarray. I don't know of any way to make these functions behave, other than adding thousands of wrappers for them in enmap, and avoiding that was the main reason for making enmap a subclass in of ndarray in the first case.

If you have an idea for a better way of doing this, I'd love to hear it.

[msyriac]

It's unfortunate that it is the ubiquitous np.asarray that causes this. I don't have a better way. I've raised the question here:
http://stackoverflow.com/questions/42126858/numpy-functions-clobber-my-inherited-dataype

Thanks for the samewcs tip.