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.

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

blas axpy test is not meaningful #255

Open
rotu opened this issue Sep 1, 2023 · 2 comments
Open

blas axpy test is not meaningful #255

rotu opened this issue Sep 1, 2023 · 2 comments

Comments

@rotu
Copy link
Contributor

rotu commented Sep 1, 2023

The axpy test checks that the return value of axpy is the same as the return value of nblas.daxpy. These functions actually have return type void so the check is just that undefined === undefined!

The actual thing saxpy/daxpy should do is mutate y in place.

deepStrictEqual(axpy('float64', n, alpha, x, 1, y, 1), nblas.daxpy(n, alpha, x, 1, y, 1));

@rotu
Copy link
Contributor Author

rotu commented Sep 2, 2023

Note this might have been at least partly obscured by TypeScript itself. Changing the dynamic require('nblas') to a static import import * as nblas from 'nblas' causes a number of typescript warnings in blas.ts to surface. Notably, blas.ts does not seem to check whether the TypedArrays match the provided dtype (or are even the same type, for multi-argument functions), which I think could lead to a runtime segfault.

@mateogianolio
Copy link
Owner

Good catch!

It's a result of having the nblas module optional. When I implemented the try..catch-require, it made typescript typing impossible because the nblas types (https://github.com/nperf/nblas/blob/master/src/types.ts) are not there because the package is not installed. Maybe there is a modern solution for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants