Support Subtract and Division of NDCube by NDData #880
Conversation
There was a problem hiding this comment.
I've tried to wrap my head around what's happening here and I don't see anything obviously problematic (though I don't know much about NDData either). My one suggestion would be adding a test that constructs an NDData from a dask array (I think this is possible??) and then apply a these operations (at least add and mul) to that object and ensure that the laziness is preserved in these new codepaths.
…preserve dask laziness.
|
@wtbarnes: Do these tests satisfy your comment? |
DanRyanIrish
force-pushed
the
nddataArithmetic2
branch
from
0c2e688 to
1bcd97f
Compare
DanRyanIrish
force-pushed
the
nddataArithmetic2
branch
from
f90bf15 to
9f9805f
Compare
|
@Cadair it looks like |
|
Oh, of course it doesn’t. Well balls. I'm not really sure what the best option is in that case then. |
Dare a say it? |
Do it |
…to nddataArithmetic2
| >>> import warnings | ||
| >>> with warnings.catch_warnings(): | ||
| ... warnings.simplefilter("ignore") # Catching warnings not needed but keeps docs cleaner. |
There was a problem hiding this comment.
I'm not a fan, it makes the warnings surprising for people following along at home. What warnings are we squashing?
There was a problem hiding this comment.
If I remember right, a warning is raised because NDUncertainty.propagate doesn't support power, and so the uncertainties get dropped.
What alternative do you suggest?
| where addition, subtraction, multiplication and division are all enabled by the ``+``, ``-``, ``*``, and ``/`` operators, respectively. | ||
|
|
||
| Note that `~ndcube.NDCube` attributes not supported by the constructor of the output type employed by `ndcube.NDCube.to_nddata` are dropped by the conversion. | ||
| Therefore, since `ndcube.NDCube.to_nddata` converts to `~astropy.nddata.NDData` by default, there was no need in the above example to explicitly set `~ndcube.NDCube.extra_coords` and `~ndcube.NDCube.global_coords` to ``None``. |
There was a problem hiding this comment.
To make sure all coordinates are dropped if you didn't know that NDData didn't support extra_coords and global_coords.
| Note that the output type of `ndcube.NDCube.to_nddata` can be controlled via the ``nddata_type`` kwarg. | ||
| For example: | ||
|
|
||
| >>> from astropy.nddata import NDDataRef | ||
| >>> nddataref2 = cube2.to_nddata(wcs=None, nddata_type=NDDataRef) | ||
| >>> print(type(nddataref2) is NDDataRef) | ||
| True |
There was a problem hiding this comment.
This feels irrelevant to the narrative here and just documentation of to_nddata, and therefore in the wrong place?
There was a problem hiding this comment.
Fair. Currently, there isn't a section anywhere on to_nddata and this code snippet probably doesn't merit one? So it might as well live here unless/until there is one.
| `ndcube.NDCube.to_nddata` is not limited to changing/removing the WCS. | ||
| The value of any input supported by the ``nddata_type``'s constructor can be altered by setting a kwarg for that input, e.g.: | ||
|
|
||
| .. code-block:: python | ||
| >>> nddata_ones = cube2.to_nddata(data=np.ones(cube2.data.shape)) | ||
| >>> nddata_ones.data | ||
| array([[1., 1., 1.], | ||
| [1., 1., 1.]]) |
There was a problem hiding this comment.
Same as this section, feels like the wrong place for this example? It's not relevant to arithmetic operations?
Co-authored-by: Stuart Mumford <[email protected]>
4 participants
To Do