ENH: spatial.transform: add array API standard support #22777

amacati · 2025-04-01T21:04:48Z

General overview

This PR adds array API support for the scipy.spatial.transform module as a step towards #18867. It allows users to create objects from the module with arrays from frameworks like torch, jax etc., and leverages these frameworks for performing the underlying operations.

Since work started when Rotation was the primary part of the module, RigidTransform has not yet been ported. However, it would be great to discuss some of the general design decisions before moving forward with the implementation of RigidTransform.

Architecture

Motivation

Previously, Rotation was a cython class centered around the rotation data represented as a quaternion. With the addition of support for the array API we can no longer use this cython code path as the universal implementation, as some arrays from other frameworks cannot be passed into cython (e.g. tensors on a GPU, jax tracers etc.).

Since the cython implementation can significantly speed up calculations with numpy arrays, and numpy remains the primary use case for the foreseeable future, we do not want to add too much overhead for the array API support.

Leveraging backends

This PR proposes an architecture that separates the implementation into:

A pure Python Rotation class that handles the interface and data storage
Backend modules that implement the actual computations.

These backends are functional implementations of Rotation's methods. Each time a Rotation is created from arrays, we check if a backend specifically for this array type has been added. If so, we use the specialized backend for all operations. Otherwise, we fall back to the new array API backend that is compatible with any array API compatible array type.

This design allows us to nicely integrate the previous, optimized cython implementation by rewriting it into a backend. We register this cython backend for numpy arrays by default, which means that numpy arrays still enjoy the speedup from compiled cython code. In addition, this also gives us a straightforward path to include optimized implementations for individual frameworks if desired, and could even be exposed to other modules that may want to register their own, specialized implementations. Here is an example of how this works in the new implementation:

# We use cython as the backend for numpy
backend_registry = {array_namespace(np.empty(0)): cython_backend}

# ... and use specialized backends if they are available in Rotation
class Rotation:
    ...
    @classmethod
    def from_matrix(cls, matrix: ArrayLike) -> Rotation:
        backend = backend_registry.get(array_namespace(matrix), array_api_backend)
        quat = backend.from_matrix(matrix)
        return cls(quat, normalize=False, copy=False)

Compiling functions

Some frameworks like jax heavily rely on jit compiled code with statically known shapes and value-independent control flow. The generic array API backend is written (and tested) to comply with these restrictions. However, this has two implications:

Error handling: Since value-based checks are no longer possible, we cannot emit certain errors. Instead, we return NaN values. However, some frameworks will raise Errors (e.g. on ill-conditioned matrices for SVDs), while others don't. This leads to an inconsistent error behaviour that we should address.
Performance: Value-based control flow is no longer possible under these conditions, meaning that both code paths often have to be run in parallel. For eager execution frameworks, this leads to unnecessary performance degradation. We could add code paths for lazy and eager execution frameworks, but that would increase the complexity of the array API backend.

Current limitations and issues

`spatial.transform.RigidTransform` support

Just like the previous Rotation implementation, RigidTransform is currently a cython class that relies on Rotation being one as well. The solution is to also convert RigidTransform into a Python class as interface, and use the same backend mechanic as with Rotation. Since the current PR already makes significant code changes with many design decisions, it makes sense to first discuss and review these before moving on to converting RigidTransform as well. The final draft may then also include full RigidTransform support.

For now, this version of spatial.transform INTENTIONALLY DISABLES RigidTransform to let the build succeed. Hence, all tests for RigidTransform are expected to fail.

array API version

The current implementation uses the latest array API standard 2024.12 with array-api-strict>=2.3 and array-api-compat>=1.11. This is necessary for advanced indexing.

Randomness

The array API does not define a standard for generating random numbers. This is probably out of scope anyways, as different frameworks have different models for randomness (compare e.g. numpy generators vs jax PRNG keys). Therefore, random constructors always return the numpy version of rotations.

Rotation splines

Rotation splines currently use scipy.interpolate, which is not array API compatible. Therefore, the current implementation errors on creating splines from a Rotation that is not backed by a numpy array.

Open issues

xp.roll needs to be clarified by the array API and array-api-compat needs to be updated for torch, or array-api-strict requires additional checks for xp.roll. See data-apis/array-api#914

Open design decisions

Rewriting Rotation with pure array API compatible code that may also be compiled by lazy frameworks requires some deviations from the original cython implementation. Sections that deviate and require some form of discussion or decision are marked with

# DECISION: ... (or sometimes with TODO:)

to make it easier for reviewers to find critical points for discussion. They mostly also add a reason why the current decision was made, and may include alternatives.

Tests

Currently, all tests for rotations have been rewritten in terms of the array API and pass locally with numpy, array-api-strict, torch and jax.

Performance

I plan on benchmarking the current implementation for various workloads similar to the benchmarks in #22500. Ideally this includes comparing it against the current version to measure the overhead of going through the backend. This may have to wait until I have some more time at my disposal though. In case this should be integrated into the airspeed suite, I'd be grateful for guidance and/or help with that.

TODOs

Add support for RigidTransform
Benchmark performance for different frameworks
Unify error handling
Discuss design decisions marked as # DECISION in the code
Move all docs to the Python Rotation class

Reference issue

Closes #22500

tylerjereddy · 2025-04-02T02:55:59Z

Error handling: Since value-based checks are no longer possible, we cannot emit certain errors. Instead, we return NaN values.

At first glance, this is a compromise I'm not particularly keen on. I'm definitely in the camp of error handling being a measure of correctness for which performance shouldn't take priority. That said, the main point in saying that is just to make sure reviewers consider the tradeoffs carefully. It may be sensible to spell out our policy on this somewhere in a tracking issue or something like that if there is already a consensus I'm not aware of. I made a similar comment about "batching" using NaNs instead of hard errors recently, but this is a separate scenario I think.

I suppose the very existence of very popular lazy execution libraries is a sort of counter point that there is substantial demand for performance over error handling. Some of the lazy libraries have eager modes for better error handling/debugging though, right? Anyway, this is something I'm worried about.

lucascolley · 2025-04-02T09:27:55Z

Error handling: Since value-based checks are no longer possible, we cannot emit certain errors. Instead, we return NaN values.

At first glance, this is a compromise I'm not particularly keen on. I'm definitely in the camp of error handling being a measure of correctness for which performance shouldn't take priority. That said, the main point in saying that is just to make sure reviewers consider the tradeoffs carefully. It may be sensible to spell out our policy on this somewhere in a tracking issue or something like that if there is already a consensus I'm not aware of.

@crusaderky may have words to add here

crusaderky · 2025-04-02T09:55:45Z

Please follow the pattern from #22342:

use xpx.lazy_apply to wrap around Cython kernels
skip error checks and warnings on lazy backends (is_lazy_array(x))
if skipping an error check can cause a segfault or infinite loop in Cython code, it needs to be pushed into the function wrapped by xpx.lazy_apply
if worthwile, offer explicit, eager validation functions
be careful about injecting NaNs, particularly if your code is meant to work with integers
use xpx.testing.lazy_xp_function to test that your code is actually respectful of lazy backends

I'm going to write a proper guide in the documentation soon.

crusaderky · 2025-04-02T09:56:41Z

I'm definitely in the camp of error handling being a measure of correctness for which performance shouldn't take priority

It's not a matter of performance. Lazy backends cannot materialize the array contents with __bool__ so that you can raise/warn.

ev-br · 2025-04-02T10:15:00Z

At first glance, this is a compromise I'm not particularly keen on. I'm definitely in the camp of error handling being a measure of correctness for which performance shouldn't take priority. That said, the main point in saying that is just to make sure reviewers consider the tradeoffs carefully. It may be sensible to spell out our policy on this somewhere in a tracking issue or something like that if there is already a consensus I'm not aware of.

A big +1 for spelling out the policy and documenting it in a centralized location. #22781

amacati · 2025-04-02T10:22:51Z

Please follow the pattern from #22342:

use xpx.lazy_apply to wrap around Cython kernels
...

Just to make sure I understand correctly: You mean you want to exclusively use the cython implementation for performing actual computations and add a conversion wrapper for frameworks other than numpy?

amacati · 2025-04-02T10:29:56Z

It's not a matter of performance. Lazy backends cannot materialize the array contents with bool so that you can raise/warn.

I was about to remark the same. The NaN vs eager raise discussion is not about performance. It's just not possible to raise with some lazy frameworks. The question is how consistent error handling needs to be between frameworks.

If it should be consistent, we either have to use NaNs also for eager frameworks, or we cannot support lazy frameworks at all.
If we allow inconsistencies between frameworks, we probably should make that explicit in the docs.

crusaderky · 2025-04-02T16:22:39Z

Please follow the pattern from #22342:

use xpx.lazy_apply to wrap around Cython kernels
...

Just to make sure I understand correctly: You mean you want to exclusively use the cython implementation for performing actual computations and add a conversion wrapper for frameworks other than numpy?

If a native dispatch is not available,
and an array API agnostic variant is not feasible (or delayed to a future date),
then as a last resort backends other than numpy - including dask and jax - should use xpx.lazy_apply to use a cython function, as long as the data is not on GPU memory.

lucascolley · 2025-04-02T16:24:24Z

right, and this PR addresses "an array API agnostic variant is not feasible (or delayed to a future date)" for spatial.transform

tylerjereddy · 2025-04-03T01:56:59Z

I was about to remark the same. The NaN vs eager raise discussion is not about performance.

I'm not sure I follow--why would we want to add lazy backend support if not for performance reasons?

The fact that we're contemplating adding the lazy backend support implies that there's a performance benefit to doing so--if performance is not involved here, what is the true motivation? What I'm saying is that if we want a single common code path for lazy and eager backends that would mean that we sacrifice error handling for the eager case, which I'm not fond of.

If we specialize code paths for lazy and eager and provide them with different error handling, that would seem to have different drawbacks that somewhat move away from the original array API implementation ideals (though I think specialized code paths have proliferated somewhat regardless).

I also don't really understand the design of the is_lazy or lazy_ shims of various sorts--can these legitimately distinguish between a potentially-lazy backend that is currently in eager mode vs. its default lazy mode for example?

In short, if you're not compromising, shimming or adjusting the error handling of the eager libraries at all, then I'm less worried. If you are making any adjustments to the error handling behavior of the eager libraries, then I maintain that this is ultimately a performance (support for lazy backends) vs. error handling matter.

scipy/spatial/transform/_array_api_backend.py

lucascolley · 2025-04-03T10:13:39Z

scipy/spatial/transform/_array_api_backend.py

+    # Make sure we can transpose quat
+    quat = xpx.atleast_nd(quat, ndim=2, xp=xp)
+    K = (weights * quat.T) @ quat
+    _, v = xp.linalg.eigh(K)


strictly, all uses of xp.linalg should be wrapped in if hasattr(xp, "linalg"). Alternatively, if no fallback implementation is easy, we can just declare that the module requires xp to implement the linalg extension. In that case, it is probably better to add a higher-level check for an early exit.

scipy/spatial/transform/_array_api_backend.py

crusaderky · 2025-04-03T12:14:26Z

I was about to remark the same. The NaN vs eager raise discussion is not about performance.

I'm not sure I follow--why would we want to add lazy backend support if not for performance reasons?

Namely, because this function may not get a substantial performance benefit from running on Dask or JAX, but everything else in the user's workflow before and after it could.

What I'm saying is that if we want a single common code path for lazy and eager backends that would mean that we sacrifice error handling for the eager case

Specifically for error handling, we don't want a single common code path because error handling is valuable for eager backends and impossible for lazy ones.

If we specialize code paths for lazy and eager and provide them with different error handling, that would seem to have different drawbacks that somewhat move away from the original array API implementation ideals

It is important to point out that we are talking about two code paths, total: one for eager and one for lazy. Which are two very broad categories of backends.
All hacks and special cases specific to a single backend are designed to be self-contained in array-api-compat and array-api-extra.

(though I think specialized code paths have proliferated somewhat regardless).

We're working to remove them, at least from the production code. Unit tests are harder to simplify as there are frequently quirks in behaviour when this or that backend diverges from the Standard.

I also don't really understand the design of the is_lazy or lazy_ shims of various sorts--can these legitimately distinguish between a potentially-lazy backend that is currently in eager mode vs. its default lazy mode for example?

They don't, by design.
JAX in eager mode is generally regarded by its developers only as a debugging/development clutch, with very little value in production use cases as it is enormously slower than numpy/cupy. So there was a conscious decision not to expose a "jitted/eager" flag, in order to reduce the testing surface in downstream projects.

Another "potentially lazy" backend is ndonnx (not yet supported by scipy), which I understand is intended mainly for ML training where it switches to lazy mode.

tylerjereddy · 2025-04-03T15:35:32Z

It is important to point out that we are talking about two code paths, total: one for eager and one for lazy.

Understood, I think my main concern evaporates then, at least for this specific case. I was worried both were being unified to the detriment of eager error handling to keep maintenance burden under control.

scipy/spatial/transform/_array_api_backend.py

amacati · 2025-04-20T23:57:15Z

I have now added full support for RigidTransform as well and all tests are passing locally. Also, error handling is now unified. Eager frameworks raise just like NumPy, lazy frameworks return NaN values.

I'll try to create some benchmarks that compare the new implementation for different frameworks and devices to the old one next. Once we have some numbers and the performance looks okay, we can maybe discuss what's left to do before this PR can be merged.

amacati · 2025-04-22T22:26:15Z

One frequent issue that is coming up while I'm going through the benchmarks: Some functions may work just fine on the CPU, but will raise device errors when the original Rotation is created on the GPU, but intermediate arrays are created on the CPU. The tests do not capture these cases at the moment. In theory, it would be necessary to run the tests for all devices. Is there precedence for this in scipy?

lucascolley · 2025-04-23T04:09:11Z

we're still thinking about how best to test devices in gh-22680

In array-api-extra, we use an enum, https://github.com/data-apis/array-api-extra/blob/main/src/array_api_extra/_lib/_backends.py. But in SciPy we also have the environment variable SCIPY_DEVICE.

lucascolley · 2025-04-23T04:12:41Z

If the important part for now is just that the same tests are ran on the GPU, that should be covered by https://github.com/scipy/scipy/blob/main/.github/workflows/gpu-ci.yml

amacati · 2025-04-23T09:03:52Z

Here are the benchmarks for Rotation. They include numpy with scipy 1.15.2, numpy with this PR, torch on CPU and GPU, jax with just-in-time compilation on CPU and GPU, and cupy. The full report is added as PDF.

There is a performance penalty for determining the array framework etc. that is mainly noticeable at sample sizes from 1 to 10. Nevertheless, this should be a very common use case, so we should probably take that serious and try to close the gap. I'm also not a cython expert, so if someone has more expertise in that area feel free to jump in with any ideas on how to improve typing etc. for more performance / less overhead.

Some samples:

Note: Some benchmarks are missing cupy. That is because the xp backend currently makes use of xp.array.mT, which will be supported in the upcoming release of cupy 14. See data-apis/array-api-compat#316

I will try to produce the same benchmark for RigidTransform asap, and then I think we are finally at a point where a serious review makes sense.

rotation_benchmark.pdf

crusaderky · 2025-04-23T13:38:51Z

There is a performance penalty for determining the array framework etc. that is mainly noticeable at sample sizes from 1 to 10. Nevertheless, this should be a very common use case, so we should probably take that serious and try to close the gap.

You mean like this 😃 data-apis/array-api-compat#308

scipy/spatial/transform/_rotation_xp.py

amacati · 2025-04-24T15:39:08Z

Still I suggest to seriously consider why this is in scipy and somewhere backend-specific, which hooks into scipy via some form of delegation.

On the contrary (with a bit of forward thinking), if we are wanting to split backend-specific code out into a separate repo, it is the NumPy-specific Cython which ought to be maintained separately.

This is why I think the backend design makes a lot of sense. It should be very easy to separate either backend out at a later time into its own package if you wish to. Adding backends back in is then just be a matter of installing scipy-accel or whatever that package would be called, and then let it register

crusaderky · 2025-04-29T07:57:30Z

There is a performance penalty for determining the array framework etc. that is mainly noticeable at sample sizes from 1 to 10. Nevertheless, this should be a very common use case, so we should probably take that serious and try to close the gap.

You mean like this 😃 data-apis/array-api-compat#308

The PR above is now in scipy main; if you merge from main and rerun the benchmarks you should see its impact.

scottshambaugh

I find this a rather difficult PR to review, since big chunks of code are split out to new files and I'm unfamiliar with the array API & its conventions.

However I am familiar with the existing tests here, and the testing of all the behavior of this module is very thoroughly covered. I reviewed the test files and barring the comments I left, I can confirm that the test suite remains functionally unchanged. This serves to prove that the code changes here have not modified the expected behavior.

scottshambaugh · 2025-05-05T17:05:59Z

scipy/spatial/transform/tests/test_rigid_transform.py

-    assert_allclose(
+    exp_coords = xp.asarray(
+        [
+            [-2.01041204, -0.52983629, 0.65773501, 0.10386614, 0.05855009, 0.54959179],


I don't have strong preference on the formatting of arrays, but it should be consistent

See the isolated testing PR #22939. I strongly agree on this one. It would be great to have at least a consistent formatter for scipy.spatial.transform.

scottshambaugh · 2025-05-05T17:08:23Z

scipy/spatial/transform/tests/test_rigid_transform.py

+            ],
+        ]
+    )
+    # The tolerance is set to 1e-8, because xp_assert_close compares the absolute difference instead


Was this test otherwise failing? The previous 1e-12 should still be a bounding absolute error to compare against here, and not including rtol would only lower the expected error. If the results are changing enough to trip the limit, it's something we should flag and dig into. (Changed in some other places as well).

The previous 1e-12 should still be a bounding absolute error to compare against here, and not including rtol would only lower the expected error

I'm not sure I follow the logic here. Yes, adjusting the implicit rtol lowers the expected error. Hence, the tests fail, as the implementation no longer meets the stricter expectation.

scipy/scipy/_lib/_array_api.py

Lines 366 to 373 in 9c02107

floating = xp.isdtype(actual.dtype, ('real floating', 'complex floating'))

if rtol is None and floating:

# multiplier of 4 is used as for `np.float64` this puts the default `rtol`

# roughly half way between sqrt(eps) and the default for

# `numpy.testing.assert_allclose`, 1e-7

rtol = xp.finfo(actual.dtype).eps**0.5 * 4

elif rtol is None:

rtol = 1e-7

1e-12 was not acting as a bounding absolute error, due to the implicit rtol.

So I don't think the change implies that the results are becoming less precise (of course, we should still check).

The important question is what mixture of atol and rtol would be most appropriate here.

I think the code comment here seems inaccurate, though: the linked lines show that rtol is set to a nonzero value when the argument is omitted, so it isn't just comparing the absolute difference.

Ah, yeah I was getting things backwards, should be fine as-is. I think the correct comparison for hardcoded digits as is done here is an atol equal to the resolution of the hardcoded number. I.e. 8 decimal places would compare to atol of 1e-8 as is done in the new code, with rtol as 0 (as appears is not being done per the linked snippet).

If swapping assert_allclose for xp_assert_close is nontrivial, it should be moved to a separate PR which can become a dependency of this one. xp_assert_close runs on non-array-api numpy too.
Basically everything that makes sense on its own as a propaedeutic step to this should be moved out in order to reduce the size of this PR as much as possible.

yes, agreed

scottshambaugh · 2025-05-05T17:09:58Z

scipy/spatial/transform/tests/test_rotation.py

-@pytest.mark.thread_unsafe
-@pytest.mark.parametrize("seq_tuple", permutations("xyz"))
-@pytest.mark.parametrize("intrinsic", (False, True))
-def test_as_euler_degenerate_compare_algorithms(seq_tuple, intrinsic):


lucascolley · 2025-05-05T18:57:12Z

BTW @amacati, it looks like you aren't the only one interested in using this! magpylib/magpylib#792

amacati · 2025-05-06T09:20:39Z

Sorry for taking so long, had a lot going on recently. I have now split up the testing into a separate PR #22939. The PR is optimized to reduce the amount of line changes, but still comes in at ~ +2000/-1200 lines. I don't think I can improve significantly on that, it's just a lot of code that has changed.

The plan for moving forward (in this order) is:

A PR to disentangle RigidTransform into a functional-style cython backend and a pure python frontend class
A PR to disentangle Rotation into a functional-style cython backend and a pure python frontend class
A PR to add the Array API backend for Rotation
A PR to add the Array API backend for RigidTransform

All reviews can focus on these isolated PRs to make things less overwhelming. Once these PRs are merged, we can close this PR (probably without merging, as its parts have been merged individually).

@ maintainers please let me know if that works for you. Splitting this PR up into stages without breaking the transform module in between is a lot more work than one might think, so it would be great to know that this effort is not in vain.

Also, I know that scipy has no consistent formatter and does not intent to have one anytime soon (see #22777 (comment)). However, it would be nice to at least have a formatter for scipy.spatial.transform, even if it's just a recommendation. Trying to match the format style of the old implementations to reduce the amount of random format changes is tedious work. Having at least a comment on how to replicate that style somewhere in the files would be immensely helpful.

lucascolley · 2025-05-06T09:51:25Z

sounds like a plan! We can add to the list: converting the tests to use the xp_assert infrastructure, separately and before making the changes needed in the implementations.

amacati · 2025-05-06T10:16:39Z

sounds like a plan! We can add to the list: converting the tests to use the xp_assert infrastructure, separately and before making the changes needed in the implementations.

Ah yes, but this is already completed in #22939 and ready for review, so I didn't list it

amacati · 2025-05-11T11:12:34Z

Array API tests from #22939 have now been merged. The PR to refactor RigidTransform into a functional-style cython backend and a pure python frontend class is now open and ready for review in #22972

[skip ci]

purepani · 2025-05-17T19:54:02Z

Did you mean to clear all the commits here?

amacati · 2025-05-18T19:20:14Z

I thought it might make sense to keep this thread open for the general discussion until everything is merged from smaller PRs and then close this PR without merging.

ev-br · 2025-05-23T18:30:11Z

Now that I looked at https://docs.jax.dev/en/latest/jax.scipy.html, apparently jax has a native implementation of jax.scipy.Rotation. Did somebody try to benchmark it against the implementation from this effort? Ideally, both in eager mode and under jit.

amacati · 2025-05-24T05:45:54Z

No, not yet. It would definitely be interesting to compare against those functions that are implemented in the jax version (it only supports a subset)

github-actions bot added scipy.spatial Cython Issues with the internal Cython code base Meson Items related to the introduction of Meson as the new build system for SciPy enhancement A new feature or improvement labels Apr 1, 2025

lucascolley requested review from nmayorov and scottshambaugh April 1, 2025 22:37

tylerjereddy added the array types Items related to array API support and input array validation (see gh-18286) label Apr 2, 2025

lucascolley reviewed Apr 3, 2025

View reviewed changes

lucascolley removed the Meson Items related to the introduction of Meson as the new build system for SciPy label Apr 3, 2025

lucascolley changed the title ~~ENH: Add array API standard support for spatial.transform~~ ENH: spatial.transform: add array API standard support Apr 3, 2025

crusaderky reviewed Apr 3, 2025

View reviewed changes

scipy/spatial/transform/_array_api_backend.py Outdated Show resolved Hide resolved

crusaderky reviewed Apr 4, 2025

View reviewed changes

scipy/spatial/transform/_array_api_backend.py Outdated Show resolved Hide resolved

lucascolley reviewed Apr 24, 2025

View reviewed changes

scipy/spatial/transform/_rotation_xp.py Outdated Show resolved Hide resolved

crusaderky mentioned this pull request Apr 25, 2025

ENH: jax_autojit data-apis/array-api-extra#284

Merged

lucascolley mentioned this pull request May 5, 2025

Support Array API Standard for Python. magpylib/magpylib#792

Open

scottshambaugh reviewed May 5, 2025

View reviewed changes

amacati mentioned this pull request May 6, 2025

TST: spatial.transform: Add array API standard support for testing #22939

Merged

amacati closed this May 11, 2025

amacati force-pushed the main branch from 5596af5 to da7717e Compare May 11, 2025 09:37

amacati mentioned this pull request May 11, 2025

ENH: spatial.transform.RigidTransform: refactor into pure Python class and cython backend #22972

Merged

amacati added a commit to amacati/scipy that referenced this pull request May 11, 2025

Reopen scipy#22777

dbcfa4f

amacati reopened this May 11, 2025

amacati added a commit to amacati/scipy that referenced this pull request May 11, 2025

Reopen scipy#22777

eca50be

[skip ci]

ev-br mentioned this pull request May 21, 2025

Tracker: array types (CuPy, PyTorch & co) and array API standard support #18867

Open

22 tasks

amacati closed this Jun 20, 2025

amacati force-pushed the main branch from eca50be to 3725530 Compare June 20, 2025 08:05

This was referenced Jun 20, 2025

ENH: spatial: optimize performance of RigidTransform #23193

Merged

ENH: spatial.transform.Rotation: refactor into pure Python class and cython backend #23198

Merged

amacati mentioned this pull request Jun 27, 2025

ENH: spatial.transform.Rotation: add array API backend #23249

Merged

4 tasks

This was referenced Aug 3, 2025

ENH: spatial: optimize performance of Rotation #23424

Open

ENH: spatial.transform.RigidTransform: add array API backend #23425

Open

	floating = xp.isdtype(actual.dtype, ('real floating', 'complex floating'))
	if rtol is None and floating:
	# multiplier of 4 is used as for `np.float64` this puts the default `rtol`
	# roughly half way between sqrt(eps) and the default for
	# `numpy.testing.assert_allclose`, 1e-7
	rtol = xp.finfo(actual.dtype).eps*0.5 4
	elif rtol is None:
	rtol = 1e-7

Uh oh!

ENH: spatial.transform: add array API standard support #22777

ENH: spatial.transform: add array API standard support #22777

Uh oh!

Conversation

amacati commented Apr 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

General overview

Architecture

Motivation

Leveraging backends

Compiling functions

Current limitations and issues

spatial.transform.RigidTransform support

array API version

Randomness

Rotation splines

Open issues

Open design decisions

Tests

Performance

TODOs

Reference issue

Uh oh!

tylerjereddy commented Apr 2, 2025

Uh oh!

lucascolley commented Apr 2, 2025

Uh oh!

crusaderky commented Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

crusaderky commented Apr 2, 2025

Uh oh!

ev-br commented Apr 2, 2025

Uh oh!

amacati commented Apr 2, 2025

Uh oh!

amacati commented Apr 2, 2025

Uh oh!

crusaderky commented Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lucascolley commented Apr 2, 2025

Uh oh!

tylerjereddy commented Apr 3, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

crusaderky commented Apr 3, 2025

Uh oh!

tylerjereddy commented Apr 3, 2025

Uh oh!

Uh oh!

amacati commented Apr 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amacati commented Apr 22, 2025

Uh oh!

lucascolley commented Apr 23, 2025

Uh oh!

lucascolley commented Apr 23, 2025

Uh oh!

amacati commented Apr 23, 2025

Uh oh!

crusaderky commented Apr 23, 2025

Uh oh!

Uh oh!

amacati commented Apr 24, 2025

Uh oh!

crusaderky commented Apr 29, 2025

Uh oh!

scottshambaugh left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

amacati commented Apr 1, 2025 •

edited

Loading

`spatial.transform.RigidTransform` support

crusaderky commented Apr 2, 2025 •

edited

Loading

crusaderky commented Apr 2, 2025 •

edited

Loading

amacati commented Apr 20, 2025 •

edited

Loading

scottshambaugh left a comment •

edited

Loading

scottshambaugh May 5, 2025 •

edited

Loading

scottshambaugh May 5, 2025 •

edited

Loading

amacati commented May 6, 2025 •

edited

Loading