Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow single/float32 precision tensor types #254

Open
iancze opened this issue Feb 28, 2024 · 0 comments
Open

Allow single/float32 precision tensor types #254

iancze opened this issue Feb 28, 2024 · 0 comments

Comments

@iancze
Copy link
Collaborator

iancze commented Feb 28, 2024

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant