v6: Rebased against master, require bitshift operands to match in sign-ness.
Maybe we can support both int32 and uint32?
Then:
- we can still write "x << 2" instead of "x << uint32(2)"
- if it's already uint32, the exception test can be removed and the…
if numpy acts up simply use
_set_promotion_stateto get the behavior that numpy are planning to implement.
The issue right now is that _set_promotion_state doesn't seem to affect bitwise…
>>> import numpy as np
>>> np._get_promotion_state()
'legacy'
>>> np._set_promotion_state("weak")
>>> np._get_promotion_state()
'weak'
>>> np.uint64(1) << np.int32(1)
Traceback (most…It seems like this issue is documented here: https://github.com/numpy/numpy/issues/22624 and https://github.com/numpy/numpy/issues/2524.
This is because the shift number is converted as a…
Apart from allowing both int32 and the LHS operand type, do you have other suggestions on how to workaround this issue?
After changing it to cast to int32 I got this error:
Checking src/operators.py... Traceback (most recent call last):
File "/home/david/programming/nac3/nac3standalone/demo/./interpret_de…accept both the type of the LHS operand and int32
That sounds like unnecessary complications. Why not just int32?
This will cause the operators.py test to require casts on all…
Actually don't merge this yet, let me break the casting changes out of this PR.