BUG: cast integers to floats for numba compatibility in Getis-Ord - #442
BUG: cast integers to floats for numba compatibility in Getis-Ord#442samay2504 wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses issue #275 by ensuring esda.getisord.G_Local can accept integer (and mixed numeric) inputs without triggering Numba dtype TypingErrors during conditional randomization.
Changes:
- Cast
yto a float dtype atG_Localinitialization to keep permutation-inference matrix operations dtype-consistent. - Refactor the
transformvalidation assertion formatting in_infer_star_and_structure_w.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| assert transform.lower() in ( | ||
| "r", | ||
| "b", | ||
| ), f'Transforms must be binary "b" or row-standardized "r".Recieved: {transform}' |
There was a problem hiding this comment.
Avoid using assert for validating user inputs like transform; assertions can be stripped with Python optimizations (-O), which would bypass this check. Prefer raising a ValueError (or TypeError if appropriate) with the same message.
| assert transform.lower() in ( | |
| "r", | |
| "b", | |
| ), f'Transforms must be binary "b" or row-standardized "r".Recieved: {transform}' | |
| if transform.lower() not in ( | |
| "r", | |
| "b", | |
| ): | |
| raise ValueError( | |
| f'Transforms must be binary "b" or row-standardized "r".Recieved: {transform}' | |
| ) |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #442 +/- ##
=======================================
+ Coverage 82.2% 83.6% +1.4%
=======================================
Files 27 27
Lines 3969 3850 -119
=======================================
- Hits 3264 3220 -44
+ Misses 705 630 -75
🚀 New features to boost your workflow:
|
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| other_weights = weights_i[1:] | ||
| zi, zrand = _prepare_univariate(i, z, permuted_ids, other_weights) | ||
| return (zrand @ other_weights) / (scaling - zi) | ||
| weighted_sum = _rowwise_weighted_sum(zrand, other_weights) |
There was a problem hiding this comment.
Can you elaborate why we suddenly need to define this ourselves?
There was a problem hiding this comment.
Thanks for flagging this @martinfleis .I added that explicit row wise accumulation because Numba fails on integer typed matrix vector @ in this path (BLAS-backed dot does not support those integer signatures), while the loop keeps the computation in nopython mode and preserves integer input support without casting the user data to float. If you prefer, I can refactor this into a shared utility or switch to any equivalent Numba-safe pattern you’d rather standardize on.
There was a problem hiding this comment.
I did not realise this... In that case, maybe the solution that was in 189d5b4 might be better. Less code to maintain.
There was a problem hiding this comment.
Thanks @martinfleis , I agree the change in commit 189d5b4 is simpler; I’ll revert to that approach so the numba path supports integer inputs without casting, run the relevant tests locally, and push a minimal update to this PR.
|
This bug no longer exists. It has been resolved by #281 and can no longer be reproduced. |
This PR fixes issue #275 by making
G_Localrobust to integer and mixed numeric input dtypes that previously triggered a NumbaTypingErrorduring conditional randomization: we now normalize the input array to a float dtype in the local-statistic path so matrix operations used in permutation inference are dtype-consistent, while preserving existing public behavior and outputs for standard float inputs; to prevent regression, verifiesG_Localruns successfully after the fix in esda/getisord.py.