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
Added built-in math functions used in constant initialization #300
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left some comments inline about more details we can add. Sorry there's a lot of text - there's a lot on my mind with this, and I might not have thought of everything yet.
I think for each function, we need to specify how many inputs it takes, what they mean, and some details about the output type. I still have many questions about some details here (which is part of why I was keen to start trying to write them out!), so I'm very open to changing a lot of what I've said in my musing comments.
In general, these functions are going to need to support more than one set of input types. This would be invalid in run-time OpenQASM 3 right now because of the "no implicit casting" rule, but since at the moment these are only valid at compile-time on constants, it might be clearest if we describe them as having a few allowed "overloads", and clearly define the types of each one. That's not something OpenQASM 3 supports for def
or extern
statements, but we're only talking about convenience functions for defining compile-time constants here, so it might be something we want. It would be good to hear other opinions on this - I will also bring it up in the types WG on Thursday. In the comments, I'll refer to the overloads I'd expect to work, but just a note that this isn't final language, and depending on discussions, we may want to change that wording / further restrict the allowed types.
For now, I've generally kept all single-argument functions having the same input and output type. That means, for example, that exp(2)
is forbidden but exp(2.0)
is allowed. I did it this way because I don't want to get an inconsistency, where sqrt(1.0)
is a float
, but sqrt(-1.0)
became complex
. My current suggestions make the syntax more restrictive than I'd like (I'd like exp(2)
with a literal "2" to "just work" if it were possible), but my current idea for how to get to this situation isn't oven-ready yet, and I don't know if it will ever be. So I've stayed conservative for now.
It seems logical that single-argument functions should return a type of the same precision. I'm not sure how this is going to work at all with functions with multiple arguments, and I don't know right now what we should recommend when you're given a literal, since they don't have an assigned width. This is also part of my not-yet-ready idea for how literals might work without having to attach a bunch of Hungarian-notation suffixes indicating their width (though I'm not entirely opposed to that).
We'll also want to specify what happens when you feed an invalid type to the function. Some languages return NaN - if we're exactly following IEEE 754 semantics, even runtime would need to support that as well - but at compile-time I think we should decree that producing a NaN is a compilation error.
Also, there are some bitwise functions that are missing as well:
|
@jakelishman all good points and like having an avalanche fall on my head :) Will have to look at this at length. |
Working on this ... |
@jakelishman w/r/t |
Some of it still needs work, awaiting more clarifying comments from @jakelishman |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I was absent for quite so long - I let myself build up such a backlog from issues on Terra and elsewhere, I'd barely looked at QASM for a month. I've left some more comments, but I've slightly forgotten if there were any more questions you wanted answers from me about.
At any rate, I'll be gone til the new year now, so happy Christmas/new year!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this really took so long. I'm happy with everything here, bar the minor typographical stuff I mentioned. The major change I had was to suggest that we just remove div
entirely - we don't have a meaning for it that differs from the /
operator, so it's probably best just to get rid of it. We can always add it back later if it becomes useful.
@jwoehr: I made jwoehr/openqasm#1 which should implement everything I commented on (and fixes a problem with |
Updates as mentioned in the review comments
Summary
Making spec conform to changes in #275
Addresses #298
Details and comments
Table added.
Minor format corrections to
types.rst
in passing.