Skip to content
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

Check for type collisions when registering a free parameter against existing inputs #14

Open
ajberdy opened this issue Nov 28, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@ajberdy
Copy link
Contributor

ajberdy commented Nov 28, 2023

No description provided.

@laurencap
Copy link
Contributor

I'm not sure this is possible right now. I think it would be after the program refactor.

Right now, when we process statement arguments, such as b in if not b, we check for FreeParameters in the statement and register them. This lets us support if not FreeParameter("b"). But it also means that when we process:

def do_not(b: bool):
    return not b

then b attempts to be registered again -- and we don't have the type information at that point, so we assume it's a float. This would look like a type collision, but it's the same symbol we already saw.

@speller26 ^ Another example of a use case for the program refactor, although it might be confusing without more context. Basically, we don't have a great way to actually track symbols. When I hit that symbol a new time, I can't tell if it's the same symbol or if it's shadowing the prev symbol.

@rmshaffer rmshaffer transferred this issue from amazon-braket/amazon-braket-sdk-python May 8, 2024
@rmshaffer rmshaffer added the enhancement New feature or request label May 8, 2024
@rmshaffer
Copy link
Contributor

rmshaffer commented May 9, 2024

Prototype branch started here to explore fixing this, which always allow input parameters to be declared at the time of registering them: main...rmshaffer/input-param-name-conflict

But as discussed above, this results in a failure in test_pulse_freeparameter_condition due to the name collision between the input parameter and the free parameter:

RuntimeError: Program has conflicting variables with name duration

C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py:203: RuntimeError

E           RuntimeError: in user code:
E
E               File "C:\Repos\autoqasm\test\unit_tests\autoqasm\test_pulse.py", line 235, in my_program  *
E                   if duration > duration2:
E               File "C:\Repos\autoqasm\src\autoqasm\operators\comparisons.py", line 90, in gt_
E                   return _aq_gt(a, b)
E               File "C:\Repos\autoqasm\src\autoqasm\operators\comparisons.py", line 101, in _aq_gt
E                   oqpy_program.set(result, a > b)
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py", line 667, in set
E                   self._do_assignment(var, "=", value)
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py", line 652, in _do_assignment
E                   to_ast(self, value),
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\base.py", line 529, in to_ast
E                   return item.to_ast(program)
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\base.py", line 417, in to_ast
E                   return ast.BinaryExpression(self.op, to_ast(program, self.lhs), to_ast(program, self.rhs))
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\base.py", line 529, in to_ast
E                   return item.to_ast(program)
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\classical_types.py", line 218, in to_ast
E                   program._add_var(self)
E               File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py", line 203, in _add_var
E                   raise RuntimeError(f"Program has conflicting variables with name {name}")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

No branches or pull requests

3 participants