-
Notifications
You must be signed in to change notification settings - Fork 45
Usability improvements #53
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
I don't really like the module rename. The XP abbreviation is pretty opaque to me. |
Everything else here looks good. I know the dependencies thing is still a TODO, but a very simple thing we can recommend now is to always start with We should also mention that the suite is designed so that it can be vendored in a library, if desired. I thought the README already mentioned that, but I guess not. Probably if someone wants to actually do that, though, they should tell us, so that we can start doing actual release tags. |
Just to be clear, "stacking" in the context of an elementwise function means testing that a function called on an array of values gives the same result as each individual value (an array is a "stack" of its 0-D elements. It might also be called "vectorizing". But it's not actually something I would expect would ever fail for elementwise functions, as opposed to linear algebra where a library might not implement stacking at all. |
It'd be good to use "stacking (also called batching)" or some such explanation. Batching is the much more commonly used word. |
XP is opaque as an abbreviation, but it's possibly the best option and seems to be the convention the spec runs with. Namely I was interested in making running pytest a lot on specific test cases easier, because even with smart shells the verbosity and underscores of "
This is what confused me, because from my understanding of what you're saying, the elementwise tests don't do this explicitly. Hypothesis will generate related examples such as |
Where is xp used in the spec? I only see it used once in the "purpose and scope" section as an example variable name for the array namespace. "array_api_tests" on the other hand matches the name of this repo, the array-api repo, and many implementations, and also is pretty self explanatory.
You don't use tab completion? It's the only file in the directory that starts with
Yes I don't think it's actually implemented yet. That's why I wanted to make a table/checklist for what's missing in the coverage, because I know there's a lot of cases where a test already exists but there's something or other that it doesn't test that it could. |
I do. It's still annoying as it's faster to write it on remotes, and even locally as my computer is slow. I think it's nice for first-time users generally as well.
Right, but 99% of the time I'm specifying tests. Sure I can stay inside the tests folder, but I prefer working in the root. |
This PR firstly introduces the term "xptests", as the brevity should make implementer lives easier (as well as ours)
array_api_tests/
toxptests/
ARRAY_API_TESTS_MODULE
toXPTESTS_MODULE
The README is updated accordingly. Additionally it:
test-coverage.md
, as I think keeping everything together is ideal, and knowing what the tests do goes hand-in-hand with the other README content.This somewhat covers #46 (comment). A future PR should expand on each function group. I need to mull this over a bit now. It'll definitely cover how "stacking" works in the context of each group.