Closes #54 Added type hints for core modules. This should improve stability of core routines and help users when writing code using MPoL in an IDE.
Closes #233. Removed convenience classmethods from_image_properties from across the code base. The recommended workflow is to create a :class:mpol.coordinates.GridCoords object and pass that to instantiate these objects as needed, rather than passing cell_size and npix separately. For nearly all but trivially short workflows, this simplifies the number of variables the user needs to keep track and pass around revealing the central role of the :class:mpol.coordinates.GridCoords object and its useful attributes for image extent, visibility extent, etc. Most importantly, this significantly reduces the size of the codebase and the burden to maintain, test, and document multiple entry points to key nn.modules. We removed from_image_properties from
:class:mpol.datasets.GriddedDataset
:class:mpol.datasets.Dartboard
:class:mpol.fourier.NuFFT
:class:mpol.fourier.NuFFTCached
:class:mpol.fourier.FourierCube
:class:mpol.gridding.GridderBase
:class:mpol.gridding.DataAverager
:class:mpol.gridding.DirtyImager
:class:mpol.images.BaseCube
:class:mpol.images.ImageCube
Closes #246 Make the passthrough behaviour of :class:mpol.images.ImageCube the default and removed this parameter entirely. Previously, it was possible to have :class:mpol.images.ImageCube act as a layer with nn.Parameters. This functionality has effectively been replaced since the introduction of :class:mpol.images.BaseCube which provides a more useful way to parameterize pixel values. If a one-to-one mapping (including negative pixels) from nn.Parameters to output tensor is desired, then one can specify pixel_mapping=lambda x : x when instantiating :class:mpol.images.BaseCube.
Removed unused routine mpol.utils.log_stretch.
Made some progress converting docstrings from "Google" style format to "NumPy" style format. Ian is now convinced that NumPy style format is more readable for the type of docstrings we write in MPoL. We usually require long type definitions and long argument descriptions, and the extra indentation required for Google makes these very scrunched.
from_image_propertiesfrom across the code base. The recommended workflow is to create a :class:mpol.coordinates.GridCoordsobject and pass that to instantiate these objects as needed, rather than passingcell_sizeandnpixseparately. For nearly all but trivially short workflows, this simplifies the number of variables the user needs to keep track and pass around revealing the central role of the :class:mpol.coordinates.GridCoordsobject and its useful attributes for image extent, visibility extent, etc. Most importantly, this significantly reduces the size of the codebase and the burden to maintain, test, and document multiple entry points to keynn.modules. We removedfrom_image_propertiesfrommpol.datasets.GriddedDatasetmpol.datasets.Dartboardmpol.fourier.NuFFTmpol.fourier.NuFFTCachedmpol.fourier.FourierCubempol.gridding.GridderBasempol.gridding.DataAveragermpol.gridding.DirtyImagermpol.images.BaseCubempol.images.ImageCubepassthroughbehaviour of :class:mpol.images.ImageCubethe default and removed this parameter entirely. Previously, it was possible to have :class:mpol.images.ImageCubeact as a layer withnn.Parameters. This functionality has effectively been replaced since the introduction of :class:mpol.images.BaseCubewhich provides a more useful way to parameterize pixel values. If a one-to-one mapping (including negative pixels) fromnn.Parameters to output tensor is desired, then one can specifypixel_mapping=lambda x : xwhen instantiating :class:mpol.images.BaseCube.mpol.utils.log_stretch.