-
Notifications
You must be signed in to change notification settings - Fork 55
Add dtype parameter to kspaceFirstOrder() (#695) #716
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
Open
waltsims
wants to merge
7
commits into
master
Choose a base branch
from
feature-data-cast-modern-api
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
8cad56c
Add data_cast parameter to kspaceFirstOrder() (#695)
waltsims dbfbee5
Rename data_cast → dtype, accept dtype-like inputs broadly
waltsims 0414f3d
Fix dtype upcast in step(); cast k-space ops + PML to self._dtype
waltsims 815dc8b
Merge remote-tracking branch 'origin/master' into feature-data-cast-m…
waltsims cd7d4f3
Fix sum() float32->float64 promotion in nonlinear path (Greptile P1)
waltsims 22ec78d
Cast FFT output to self._dtype (fix dtype upcast on numpy < 2)
waltsims d545952
Add staggered-velocity dtype regression test
waltsims File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unstagger_opsalso built with1j *literal → alwayscomplex128on numpy < 2The same Python-literal promotion issue as
op_grad_list/op_div_listapplies here:-1j * self.k_list[ax]iscomplex128on numpy < 2, regardless ofk_listdtype. Cast toself._complex_dtypeafter construction to keep the unstaggering FFT in the correct precision.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verified empirically on numpy 1.26.4:
-1j * k_f32 * spacing / 2evaluates to complex64 andnp.exp(...)preserves complex64 — Python complex is a weak type just like Python float/int, so the multiplication chain stays in complex64 whenk_listis float32. Sounstagger_opsis already complex64 without an explicit cast.Additionally, the prior commit (22ec78d) already added
.astype(self._dtype, copy=False)to the staggered ifftn .real line in step(), so the recorded output stays float32 even if unstagger_ops were ever to change precision.Added a regression test (d545952) that records
('p', 'ux_staggered', 'uy_staggered')withdtype=np.float32and asserts each is float32 — locks the behavior in for both numpy 1.26.4 and 2.2.6.@greptile-apps re-review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The empirical result doesn't match what NEP 50's own migration table documents. The NEP 50 spec explicitly shows the old (numpy < 2) vs new (numpy ≥ 2 / NEP 50) behaviour:
(3j + array(3, complex64)).dtypecomplex128complex64(float32(1) + 1j).dtypecomplex128complex64Source: https://numpy.org/neps/nep-0050-scalar-promotion.html
Python complex literals are not weak types in numpy < 2 — they behave like
np.complex128in the type promotion system. The "weak scalar" treatment is exactly what NEP 50 introduced. So on numpy 1.26.4,-1j * k_f32 * spacing / 2→complex128, andnp.exp(...)of acomplex128array →complex128.It's possible the empirical test ran against a numpy 2.x environment, or that
k_list[ax]was alreadyfloat64at the point of measurement (defeating the test). The regression test added in d545952 checks recordedsensor_data["p"]and"ux_staggered"dtypes, but those go through the.astype(self._dtype, copy=False)guard added instep()— so they'll pass regardless of whatunstagger_opsitself is. The dtype ofunstagger_opsisn't directly asserted.The fix remains: cast the list comprehension result to
self._complex_dtype:Tip: You can give me more context with .greptile/rules.md so I get this right next time.