Open kevinsung opened 4 years ago
Urgh, this is probably all over the code base. Could you check if it's a numbers.Number
? Checking for that might be the fix.
Indeed, it is a numbers.Number
. That is the way to go then.
In many instances it may be more appropriate to check against numbers.Integral
, numbers.Real
, and numbers.Complex
to verify that the code will behave as expected w.r.t. integer vs. floating point arithmetic or other similar concerns.
For the specific problem given by the example test, replacing our number checks with these other checks won't fix the problem. We also need to add cases for multiplication and for each other operation we want to support to the referenced method. Otherwise, numpy will have no idea what to do with our Cirq objects and the same error message will result. For these other operations, we will need to cast the numpy numbers into python numbers to avoid an infinite recursive loop. Adding support for numpy data types in dunder methods will have similar complexity anywhere else in the code base we want to include them. Similar complications also exists for sympy symbols that are numbers.
Unfortunately numpy 1.20 type hints doesn't seem to like numbers.Complex
as coercible to numpy array.
Instances of np.int64 are not instances of int, leading to unhandled cases. For instance,
gives