@Alexboiboi @OrtnerMichael
This is able to be merged as is(assuming the CI passes) since this just adds some tests for the core functions. They don't cover every case for every core function, but it's at least a start, and makes it a bit more convenient to test the array api rewrite.

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.51%. Comparing base (59b71f0) to head (27140f2).
Report is 804 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff             @@
##             main     #860      +/-   ##
==========================================
- Coverage   99.77%   99.51%   -0.26%     
==========================================
  Files          52       55       +3     
  Lines        5660     7477    +1817     
==========================================
+ Hits         5647     7441    +1794     
- Misses         13       36      +23     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Alexboiboi @OrtnerMichael This is able to be merged as is(assuming the CI passes) since this just adds some tests for the core functions. They don't cover every case for every core function, but it's at least a start, and makes it a bit more convenient to test the array api rewrite.

If I understand this correctly, you want have a subset of the tests here to test against different libs that support the array-api standard?
Anyway I don't think it is necessary every field calc test goes through multiple backends.

Sort of, but it's a bit more complicated.

The core tests are useful because those are the only parts I'm currently converting to the array API standard. Having the core tests here means that, when I convert to the array API standard, I can use the array-api-strict library to test for compliance, at which point it's really easy for me to just run the tests and see if the tests pass to know that the conversation is correct. Ideally this can be done in every test case so that every code path is correctly tested; that's not done here, but it's at least a start.

However that's not quite the whole story. The array-api-strict library doesn't differentiate between lazy backends(like jax and dask) and eager backends (like numpy). Since these 2 styles are pretty fundamentally different, just converting enough to pass array-api-strict isn't quite enough to get the lazy backends working. So because of that, it would be good if we could get tests passing for at least the following backends:

• numpy
• array-api-strict
• jax
• dask

Additionally, these are the tests for the exact functions I'm converting, whereas all the other tests so far(at least as far as I can tell) are further up in the chain of abstraction, so I would only be able to test them with numpy, unless I also converted more of the code. Having these tests lets me test against the minimal amount of code necessary to convert the lowest level to the array API standard