ENH: add crude assert_allclose; use value testing in vecdot

[ev-br]

No description provided.

[ev-br]

This should fail with array_api_strict until data-apis/array-api-strict#98 lands.
(verified locally that it passes with numpy and fails with array-api-strict; both with --max-examples 10000)

[asmeurer]

The CI here passes. It might be because the CI doesn't run enough examples by default and didn't catch the error.

[asmeurer]

It would be a good idea to run this with a lot of examples. My worry is that we will see the same sorts of flaky falure issues we saw with #168 due to loss of significance unless we filter out ill conditioned inputs (as in #290).

Of course, we can always just merge this and revert it or fix it if issues crop up. The CI here doesn't run many examples relatively speaking, but the CI for array-api-strict and array-api-compat is where you usually find the errors, because they have such a large matrix that they rarer errors are very likely to show up (that is assuming the test in question isn't already being XFAILed for some reason).

[asmeurer]

There's also some similar helpers in test_operators_and_elementwise_functions.py (that file has some of the more complex helper functions, since most of the tests are very similar).

[ev-br]

An alternative strategy, in view of #314 (comment), could be to only test "exact" things in hypothesis (rename assert_equal to assert_equal_if_int or some such) and add fp value testing only for specific functions with fixed inputs, as regular regression tests without hypothesis.

[asmeurer]

Yes, it's a possibility. It's not something we've really done yet, but maybe we should think about it (see also #284). Non-hypothesis tests have their own issues, which is that they only test specific things. The hypothesis tests have been pretty good at checking a wide range of cases which would definitely be missed with traditional testing. I would definitely strongly encourage the majority of the test suite to continue to use hypothesis. Even something simple like a function with n keyword arguments has something like $2^n$ possible combinations of inputs, and in many cases these combinations do materially affect each other.

And I do agree we should rename functions to be more descriptive of what they are actually doing.