Skip to content

fix: Accept float64 positions in the Ritter bounding sphere - #85

Open
kylebarron wants to merge 1 commit into
modernize/pyprojectfrom
fix/ritter-float64
Open

kylebarron wants to merge 1 commit into
modernize/pyprojectfrom
fix/ritter-float64

Conversation

@kylebarron

@kylebarron kylebarron commented Oct 5, 2026 •

Copy link
Copy Markdown
Owner

Note

This PR was written by Claude (Claude Code), not by @kylebarron.

Fixes encode failing under numpy 2 when the Ellipsoid axes are numpy float64 scalars.

The bug

encode(f, positions, indices, ellipsoid=Ellipsoid(np.float64(a), np.float64(b)))
# ValueError: Buffer dtype mismatch, expected 'float32_t' but got 'double'

The Ritter bounding sphere's second pass is written in Cython and only accepts float32. encode casts its input to float32, so this used to be unreachable from it. Under numpy 2's promotion rules (NEP 50), numpy scalars are no longer demoted to the array's dtype, so to_ecef returns float64 for such an ellipsoid and the Ritter pass rejects it. The same call works on numpy 1.26. Calling bounding_sphere directly with float64 positions fails on both versions.

Fix

Cast positions to float32 before the Ritter pass. That's the precision it has always used, so output is unchanged.

Tests

test_bounding_sphere_float64 (default and ritter methods) and test_encode_ellipsoid_numpy_scalars. All three fail without the fix and pass with it.

🤖 Written by Claude Code

The Ritter second pass is written in Cython and only accepts float32
arrays, so `bounding_sphere` with the default or `'ritter'` method raised
`ValueError: Buffer dtype mismatch, expected 'float32_t' but got 'double'`
for float64 positions.

`encode` casts its input to float32, so this used to be unreachable from
it. Under numpy 2's promotion rules (NEP 50), numpy scalars are no longer
demoted to an array's dtype, so an `Ellipsoid` whose axes are numpy float64
scalars now makes `to_ecef` return float64, and `encode` fails. On numpy
1.26 the same call succeeds.

Cast positions to float32 before the Ritter pass, which matches the
precision it has always used.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kylebarron
kylebarron added this pull request to stack #91 October 5, 2026 21:52

This branch has not been deployed

No deployments
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

Successfully merging this pull request may close these issues.

1 participant