Skip to content
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

Operator tests #35

Merged
merged 11 commits into from
Dec 6, 2021
Merged

Operator tests #35

merged 11 commits into from
Dec 6, 2021

Conversation

honno
Copy link
Member

@honno honno commented Oct 29, 2021

Should resolve #27, if partially. Commits start from #32.

Currently just parametrizes expressions to evaluate. As expected, testing the inplace operators require more thought.

@asmeurer
Copy link
Member

asmeurer commented Nov 1, 2021

We could test the operator methods like x1.__add__(x2) instead of x1 + x2. That may remove the need to do eval. In particular, we can use the operator module to treat x1 + x2 as the function operator.__add__.

It would also make it possible to test the right operators like __radd__, which aren't otherwise easy to test (although to be fair, this also implies that these methods aren't actually that important).

@honno
Copy link
Member Author

honno commented Nov 3, 2021

(I've come up with a solution, so now there's full test coverage of the respective standard and inplace operators of the elementwise tests, as well as scenarios where scalars are in play... it's not worth reviewing yet though as things are still in flux)

  • Test with both (Python scalar) integers and floats where appropriate bit tricky, prob something to leave for a future PR

@asmeurer
Copy link
Member

Sorry I've fallen a bit behind in reviewing. Is this PR ready for review and merge?

@asmeurer
Copy link
Member

Why was the broadcasting test moved to meta/? It seems to me that it's an actual test of array API module behavior, not a meta test.

@honno
Copy link
Member Author

honno commented Nov 30, 2021

Sorry I've fallen a bit behind in reviewing. Is this PR ready for review and merge?

Yep, review ready, and potentially merge ready if you're happy with it.

Why was the broadcasting test moved to meta/? It seems to me that it's an actual test of array API module behavior, not a meta test.

Ah IIRC it was actually testing your custom implementation of the broadcasting algo from the spec, so I moved it there to clarify that. Oh maybe not, I may of accidentality moved test_broadcasting_hypothesis as well. I can go through the commit history tomorrow to see what was going on. The other tests are definitely meta tests.

@asmeurer
Copy link
Member

asmeurer commented Nov 30, 2021

I implemented the algorithm from the spec and use it as a baseline to test the array API library. I suppose we could split out the testing of the algorithm itself into meta tests, but the main point is to test the broadcasting behavior in the array library.

To be sure, this test is less important now that we actually have tests for the actual functions. So maybe it should be refactored. A line in each multiarg function test like assert res.shape == _broadcast_shapes(x1.shape, x2.shape) is basically equivalent. Unlike type promotion, there may not be much benefit to having it separate once the actual function tests exist. Perhaps this was your reasoning for moving things around?

@honno
Copy link
Member Author

honno commented Dec 1, 2021

To be sure, this test is less important now that we actually have tests for the actual functions. So maybe it should be refactored. A line in each multiarg function test like assert res.shape == _broadcast_shapes(x1.shape, x2.shape) is basically equivalent. Unlike type promotion, there may not be much benefit to having it separate once the actual function tests exist. Perhaps this was your reasoning for moving things around?

It wasn't, I just made a mistake haha. But now that you mention that, we are indeed testing broadcasting for all the related functions (or should be), so I believe we don't need it anymore. I've just removed the method. Whilst parametrized tests for broadcasting is nice, I think it's the right decision not to specifically test broadcasting (just like we removed those complicated test_type_promotion.py tests). You think that's okay?

@asmeurer
Copy link
Member

asmeurer commented Dec 1, 2021

Yes, this sounds good. In the future, we might have to think about if we need to split tests up to help implementers who may want to test certain things even when other things aren't working. But that's something we should think about only once it becomes an issue. We may find that the most practical method for implementers will be to just directly comment out broken bits to see if other parts work. For now the test suite is heavily biased toward conforming or nearly conforming libraries, and it will be difficult to make it otherwise without some specific example to work against.

@asmeurer
Copy link
Member

asmeurer commented Dec 6, 2021

Merging this so that the other PR based on it is easier to review.

@asmeurer asmeurer merged commit 977bcef into data-apis:master Dec 6, 2021
@honno honno mentioned this pull request Dec 22, 2021
@honno honno deleted the operator-tests branch February 28, 2024 13:20
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.

Tests for operators
2 participants