Skip to content

Conversation

@iksnagreb
Copy link
Collaborator

When the FINN datatype is, for example, UINT64, np.random.randint still implicitly defaults to np.int64, making the high=finn_dt.max() + 1 exceed the valid range: ValueError: high is out of bounds for int64. This happened to me in the step_make_pynq_driver of a FINN build of a Gather/Lookup node where the index input has been annotated to UINT64.

I think, the most generic solution to this is specifying the numpy datatype corresponding to the FINN datatype as an additional dtype= argument to the function call. I am not sure whether it makes sense to add this to all the other cases as well, i.e., to BINARY, BIPOLAR and FLOAT32.

@jmitrevs
Copy link
Collaborator

Why weren't tests run? The change looks fine, but I want to make sure the tests pass.

@iksnagreb
Copy link
Collaborator Author

Why weren't tests run? The change looks fine, but I want to make sure the tests pass.

Hm, I don't know... I will try to rebase this on top of main and force-push to trigger the tests.

@iksnagreb iksnagreb force-pushed the fix/gen_finn_dt_tensor branch from 45cfa03 to 99dd4dc Compare January 30, 2026 17:22
@jmitrevs jmitrevs merged commit b61314d into fastmachinelearning:main Feb 2, 2026
3 of 4 checks passed
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

Successfully merging this pull request may close these issues.

2 participants