-
Notifications
You must be signed in to change notification settings - Fork 201
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
cannot unify numpy.int? with float #653
Comments
The argument is a float. Give it a float. |
|
No. It's not inconsistent |
It implicitly becomes a float after unit processing. The same happens in the following example too.
OK I was imprecise. 0.5 turn is 1*pi rad is 180 deg. |
@whitequark Thoughts on this? |
@jbqubit It is possible to implement automatic coercions for argument passing in ARTIQ Python, but due to the way type inference works, it's a zero-sum game: for every case where I add a possible coercion, there will be another case where a type annotation is now mandatory. Especially since that will break existing code, I think this feature is a net negative, and in any case the added effort would seem to be higher than fixing the type of a numeric constant. |
@whitequark Ya, mandatory type annotation isn't desirable. Thanks for the comment. |
|
@jbqubit To add to this, automatic coercions for arithmetic operations already result in necessity for type annotations in some cases. E.g. this function on its own is ambiguous: def add(x, y):
return x + y This is not a very large problem right now because passing a variable with a known type, say a field, to such a function monomorphizes it. But if every argument were subject to coercion, that would become impossible. |
https://github.com/m-labs/artiq/blob/master/artiq/language/units.py
The text was updated successfully, but these errors were encountered: