-
Notifications
You must be signed in to change notification settings - Fork 45
More promotion test cases #30
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
Conversation
f2ceeb1
to
a25dfa8
Compare
I think I've covered every method now (save extensions). Parametrizing is a bit difficult given subtle differences in these methods, so something I'd recommend we can think about later. I made a Hypothesis strategy for 2-or-more promotable dtypes... it minimises okay, some room for improvement if/once I test for it. Like with the elementwise/operator tests, I'm covering multi-dimensional arrays. The func name and respective dtypes are now included in all the error messages. I thought to keep that information at the end, so that in truncated scenarios the user can see the relevant bug information next to the test case name.
|
@given(shapes=hh.mutually_broadcastable_shapes(2, min_dims=1), data=st.data()) | ||
def test_matmul(in_dtypes, out_dtype, shapes, data): | ||
x1 = data.draw(xps.arrays(dtype=in_dtypes[0], shape=shapes[0]), label='x1') | ||
x2 = data.draw(xps.arrays(dtype=in_dtypes[1], shape=shapes[1]), label='x2') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
matmul needs the input shapes to align (see the conditions in test_matmul
).
So it looks like none of the functions outside of elementwise are actually testable with the same test as elementwise. I wonder if we should just test the type promotion for these functions in their normal function tests, like I've done here
|
1461f9a
to
67a2d6b
Compare
I see what you mean about the limitations of the non-elementwise dtype promotion tests. To prepare for a future where we're testing the 2-or-more array-accepting methods, I've made Respectively I've factored out my util I've also created
Mhm this is annoying. I'll keep this problem in the back of my mind, but yeah just asking authors to keep a high |
array_api_tests/pytest_helpers.py
Outdated
in_dtypes: Tuple[DataType, ...], | ||
out_name: str, | ||
out_dtype: DataType, | ||
expected: DataType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function feels like it has too many arguments. expected
could just default to taking the result type of the in_dtypes. Is the out_name really needed either?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I've defaulted expected
to the promoted result type. For tests that have different needs (i.e. returning xp.bool
), they can pass that instead.
I've kept out_name
but defautled it to out.dtype
. I like the error message following the spec notation, so for most cases that means testing the dtype
attribute of the out
array, i.e. out.dtype
. Again we can pass a different name for the odd diverging tests, such as meshgrid()
where we're testing the out[i].dtype
(for i
in len(out)
), or the inplace tests where it's x1.dtype
.
Basically, for the test suite's purposes this is now usually 3 arguments to worry about (func_name
, in_dtypes
, and out_dtype
).
Also we should note that single argument functions need to test dtypes too. They usually just return the same dtype as the input, but it's still something that needs to be tested. |
6fa2f9c
to
2876e61
Compare
|
Looks like your other PR created merge conflicts with this one. |
assert_dtypes looks better. We should definitely just use separate tests for the non-elementwise functions. Maybe you can add a comment that that those tests will be moved into the main tests once they are written. |
`numpy.array_api.matmul` currently doesn't support broadcastable shapes
3c8c7a8
to
0ee54b2
Compare
We now test that `two_mutual_arrays()` generates mutually promotable dtypes
f41077e
to
2d91340
Compare
And update NumPy workflow to xfail the failing new test cases
Fixed and done! I should also note that for |
I didn't realize np.tensordot doesn't broadcast. I wonder if that is intentional. It should be easy enough to fix in the implementation. For meshgrid we should figure out if that is intentional too. But either way, we should make the tests match the spec until the spec is updated. |
To remind ourselves, Atahn pointed out that PyTorch requires input arrays to have the same dtype (and so ignore type promotion issues altogether... but that would have to change if the spec remains). https://github.com/tensorflow/tensorflow/blob/v2.6.0/tensorflow/python/ops/array_ops.py#L3650 |
This should help resolve #24. Starts from the unmerged #26 so the commit history is currently messy. I'm going to try cover some more methods before seeing about a refactor.