-
Notifications
You must be signed in to change notification settings - Fork 106
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
Small Discrepancy between Real and Fourier Space Shift #1231
Comments
I couldn't reproduce the exact result you had. On my laptop, this results in the following: A little bit smaller residuals, and a different pattern. Apparently the rounding behavior on my laptop is somewhat different than on collab. If you use double precision though, the differences are ~1.e-15. So I think this isn't a problem with the method per se. Just single-precision floating point errors accumulating. But they are a fair bit higher than the single-precision epsilon value, so I switched the code to use double precision for the phases, which basically fixed it. cf. #1234 |
Hum interesting, I wouldn't have guessed platform-specific discrepancies at that level. But ok, if you recover 1e-15 using double precision then you are right it's not related to an approximation in this formula used to compute the phase. |
The first equation is nominally exact, but can have rounding errors. The line you pointed to was intended to get back to |z|=1, which it does to the accuracy of the data type. So the errors are just that numerical rounding errors can add up, maybe semi-coherently, rather than purely randomly. And apparently differently on different systems. That surprised me too, FWIW. |
Done. #1234 |
While working on porting new features to jax-galsim, we noticed that the GalSim phase shifts are not exactly equivalent to the real domain equivalent.
Here is an example of what I mean:
notebook
So, it's definitely small, but not a nice pattern...
My guess... is that it might have something to do with this:
GalSim/src/SBTransform.cpp
Line 749 in 3a9ab46
because when we use the exact expression in jax-galsim we recover perfectly the same answer as drawing the image in real space.
Just wanted to report this to see if this is known/not a big deal. Feel free to close this issue if this is the case :-)
The text was updated successfully, but these errors were encountered: