You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a ndarray_type_registry which is used for both N-D arrays and Cuda arrays. In order to use the same object for Cuda arrays we have code such as the following:
This code could be clearer as it is not clear where the [3:] comes from unless we are familiar with find_in_ndarray_type_registry. It is also not very future proof as it will be very hard to find statements like this should the prefix ever change length. Furthermore if the ndarray_type_registry is used for cuda types too then its docstring should be updated to make it clear that it affects more than just ndarrays.
To clear this up I recommend changing the function to find_in_array_type_registry
Code can then do:
Currently we have a
ndarray_type_registry
which is used for both N-D arrays and Cuda arrays. In order to use the same object for Cuda arrays we have code such as the following:This code could be clearer as it is not clear where the
[3:]
comes from unless we are familiar withfind_in_ndarray_type_registry
. It is also not very future proof as it will be very hard to find statements like this should the prefix ever change length. Furthermore if thendarray_type_registry
is used for cuda types too then its docstring should be updated to make it clear that it affects more than just ndarrays.To clear this up I recommend changing the function to
find_in_array_type_registry
Code can then do:
While array code would instead do:
Alternatively to avoid code duplication, we could also keep
self.find_in_ndarray_type_registry
:The text was updated successfully, but these errors were encountered: