Is your feature request related to a problem or opportunity? Please describe.
In its current form (v0.2), MPoL uses float64 (or complex128) tensor types everywhere. This is because very early in MPoL development, I made the decision for core modules like BaseCube to use tensors of this type. All of the downstream code then builds on tensors of this type. If I recall correctly, I think I made the decision to use float64 because I had some divergent optimisation loops with float32 and I thought loss of precision was at fault because of the large dynamic range of astronomical images. With a few years of understanding between now and then, it seems more likely that the optimisation simply went awry because of a bad learning rate and finicky network architecture (e.g., no softplus or ln pixel mapping), but I never got to the bottom of the issue.
Describe the solution you'd like
In a test branch, create a MPoL version that will run with float32 and complex64 types
Evaluate if 'modern' MPoL can successfully run to completion with single precision, and what speed up this affords over float64 (if any)
If single precision improves performance, do not enforce type float64 in MPoL objects.
single precision will also allow MPoL to run on Apple MPS, which does not work with float64.
Is your feature request related to a problem or opportunity? Please describe. In its current form (v0.2), MPoL uses
float64(orcomplex128) tensor types everywhere. This is because very early in MPoL development, I made the decision for core modules like BaseCube to use tensors of this type. All of the downstream code then builds on tensors of this type. If I recall correctly, I think I made the decision to usefloat64because I had some divergent optimisation loops withfloat32and I thought loss of precision was at fault because of the large dynamic range of astronomical images. With a few years of understanding between now and then, it seems more likely that the optimisation simply went awry because of a bad learning rate and finicky network architecture (e.g., no softplus or ln pixel mapping), but I never got to the bottom of the issue.Describe the solution you'd like
float32andcomplex64typesfloat64(if any)float64in MPoL objects.float64.