| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Makes sense!
Maybe run this past the community meeting on Thursday? cc @tylerjereddy for viz |
Sorry, something went wrong.
|
We briefly discussed this in the community meeting on June 25, and the reception was positive. The implementation LGTM, and the conflict with gh-206 will need to be resolved one way or another. So no reason to not merge this. Thanks @betatim ! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
While doing some work on scikit-learn I discovered that the device type ID for arrays that are not using the default device are still equal to the CPU device type ID. The reason I noticed is that I was exploring using the DLPack device type ID as a way to tell if something was on the CPU or "some other device" in a array namespace neutral way. Being able to use array-api-strict to test code and pretend to be on a "GPU" is useful because you can run those tests without actually having a "not CPU" device.
I think it makes sense to make the device type ID consistent with how the additional devices in array-api-strict work. They are meant to be devices from which you can't np.asarray(my_array) and simulate a "GPU" device that has its own memory, etc.
The result is this PR. This is how things look when you use it:
I am not particularly attached to the actual implementation. It is the result of asking AI to make a sketch of how this would look and feel. I've not tried to find things that break as a result of this change beyond writing new tests and running the test suite. You could argue that this should be an issue instead of a PR, but I had the code so I thought I'd put it up so people can look at it.
What do y'all think about the idea of changing the device type ID for arrays that use one of the non-default devices?
Kinda related to #70