Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Improve type checking in ufuncs #80

Open
NaderAlAwar opened this issue Sep 7, 2022 · 1 comment
Open

Improve type checking in ufuncs #80

NaderAlAwar opened this issue Sep 7, 2022 · 1 comment
Labels
ufuncs

Comments

@NaderAlAwar
Copy link
Contributor

Currently we're checking view datatypes in ufuncs using string comparison (e.g. here). The reasons are explained in Tyler's comment here. This can break quite easily later and is also not desirable for performance reasons.

Additionally, ufuncs with two operands only allow specific combinations of types (e.g. here), when they should be less restrictive in what combinations of types are allowed. As mentioned in Tyler's comment, we want to have a system for type promotion.
@NaderAlAwar NaderAlAwar mentioned this issue Sep 7, 2022
Merged
@tylerjereddy
Copy link
Contributor

There's a detailed discussion/proposal to standardize the approach to data type inspection in the next version of the array API standard here: data-apis/array-api#425

So, we may want to follow something similar to whatever they decide on there, if feasible.

tylerjereddy added a commit to tylerjereddy/pykokkos that referenced this issue Dec 18, 2022
@tylerjereddy
ENH: ufunc dispatcher/concision
05067f1 
* use a ufunc workunit dispatcher to improve
concision of the ufunc code for these ufuncs,
as an initial demonstration:
  - `isfinite()` (`parallel_for`)
  - `equal()` (`parallel_for`)
  - `isinf()` (`parallel_for`)
  - `matmul()` (`parallel_reduce`)
  - `reciprocal()` (`parallel_for`)

* the reduction in LOC is around: 250

* the changes do not guarantee identical behavior
beyond the testsuite passing, so for example
error handling behavior may not be fully preserved

* our type system still needs a cleanup to make
things more consistent per kokkosgh-80
@tylerjereddy tylerjereddy mentioned this issue Dec 18, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ufuncs
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tylerjereddy @NaderAlAwar