ENH: test vecdot values, incl complex conj #314
Conversation
Preferred as long as xp.isdtype is not universally available (looking at you pytorch)
|
Let's get this in and see if this causes any issues going forward. |
| else: | ||
| true_val = None | ||
| def true_val(x, y, axis=-1): | ||
| return xp.sum(xp.multiply(_conj(x), y), dtype=res.dtype) |
There was a problem hiding this comment.
Unfortunately, if you look here, there is no approximate testing done at all for floating-point values https://github.com/data-apis/array-api-tests/pull/314/files?diff=unified#diff-6056c0b3af9cd3ba66387432a17f5f36bbd54220419656441a8b01bcdc4df44bR57.
We should probably add a flag to that helper to allow approximate testing to be enabled. Some functions are impossible to do approximate testing for because they don't even have a single possible output (e.g., eigh could pick completely different eigenvectors and still be correct).
There are helpers used in the elementwise functions that could be reused here for testing floating-point (and complex) closeness. Basically, they test with very large epsilons. Even that would be enough to detect that a library isn't conjugating, which is the real concern for this test specifically.
There was a problem hiding this comment.
Wait, what: https://github.com/data-apis/array-api-tests/blob/master/array_api_tests/test_linalg.py#L109 and I was sure this PR switches on equality testing. But assert_equal does not do what name the implies:
https://github.com/data-apis/array-api-tests/blob/master/array_api_tests/test_linalg.py#L49
There was a problem hiding this comment.
Yes, I originally had it there but later had to comment it out when I found out that you fundamentally can't compare floating point stacks for some functions like eigh because sometimes implementations (like CuPy) use different algorithms that give different (but still mathematically correct) results. #101 (comment) I never renamed the functions. While I did turn the floating-point checks off completely, and they don't make sense for some functions like eigh, they do make sense for functions like vecdot and others where the mathematical answer is has a single well-defined value. We just need to be careful about loss of significance, especially for the tensor contraction functions (vecdot, matmul, tensordot, etc.) that involve additions.
Add a value test for
vecdotfor real and complex fp types: this is a matching test for data-apis/array-api-compat#201 and data-apis/array-api-strict#98A weird thing is that the test should fail without data-apis/array-api-strict#98 but locally it does not. Probably I'm not generating enough examples---is there a way to bump the number with a cmdline switch? Tried several variations of
python --max-examples=100but no luck so far.closes gh-312