This issue proposes a new analysis subpackage for functions that take NDCubeABC instances and perform some analysis task. The scope of this subpackage should be as follows:
functions must only require the NDCube 2 API in order to carry out the entire task;
functions do not have to be valid for all possible NDCube instances, but they must be general enough to be beyond the scope of an astronomy-sub-field-specific package. For example:
fitting a spectral line is beyond scope because it requires an understanding of a model and a fitter API which is not included in the NDCube 2 API;
Differentially rotating an image of the Sun is beyond scope because this is specific to the field of solar physics;
cropping just the celestial axes of a cube is within scope because, although it only applies to cubes with celestial axes, the task can be performed exclusively using the NDCube 2 API and is useful across multiple sub-fields of astronomy.
The subpackage should contain modules which encompass certain types of tasks. As a start, this issue proposes the following modules:
ndcube.analysis.rebin
This can hold a rebin function equivalent to NDCube.rebin, but can also hold a function to irregularly rebin a cube, which, due to technical limitations at this time, can only be performed when all WCS axes are independent.
ndcube.analysis.crop
This can hold a crop function equivalent to NDCube.crop, but can also contain functions to only crop the celestial axes, e.g. crop_celestial. The advantage of this is that more user-friendly APIs can be exposed to the user. The same could be done for crop_temporal, crop_spectral etc.
NDCube methods vs. analysis functions
Similar to numpy, NDCube can have methods that simply call an analysis function, e.g., rebin and crop. But when should NDCube have a method as well as an analysis function? The criterion for a method to exist should be that:
Methods should apply to all possible NDCube instances, i.e. it should be completely agnostic to the number of dimensions and physical types associated with them. For example:
NDCube.crop should exist, even if ndcube.analysis.crop.crop() also exists. However, while ndcube.analysis.crop.crop_celestial is a valid anaylsis function, it should not be a method because it is only valid for cubes with celestial axes.
DanRyanIrish
commented
3 weeks ago
Describe the feature
This issue proposes a new
analysissubpackage for functions that takeNDCubeABCinstances and perform some analysis task. The scope of this subpackage should be as follows:NDCubeinstances, but they must be general enough to be beyond the scope of an astronomy-sub-field-specific package. For example:The subpackage should contain modules which encompass certain types of tasks. As a start, this issue proposes the following modules:
ndcube.analysis.rebinrebinfunction equivalent toNDCube.rebin, but can also hold a function to irregularly rebin a cube, which, due to technical limitations at this time, can only be performed when all WCS axes are independent.ndcube.analysis.cropcropfunction equivalent toNDCube.crop, but can also contain functions to only crop the celestial axes, e.g.crop_celestial. The advantage of this is that more user-friendly APIs can be exposed to the user. The same could be done forcrop_temporal,crop_spectraletc.NDCubemethods vs. analysis functionsSimilar to
numpy,NDCubecan have methods that simply call an analysis function, e.g.,rebinandcrop. But when shouldNDCubehave a method as well as an analysis function? The criterion for a method to exist should be that:NDCubeinstances, i.e. it should be completely agnostic to the number of dimensions and physical types associated with them. For example:NDCube.cropshould exist, even ifndcube.analysis.crop.crop()also exists. However, whilendcube.analysis.crop.crop_celestialis a valid anaylsis function, it should not be a method because it is only valid for cubes with celestial axes.Proposed solution
No response