You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fanout/fanin are checkable currently so the places they can be used is limited, but we could guess at the expected size using the nat-solving framework, they'd be much more useful!
e.g.
f(Vec(Qubit, 2)) -o Bit
f = ...
g(Qubit, Qubit) -o Bit
g = [\/]; f
h(Qubit, Qubit) -o Bit
h = [\/]; ..; f
g succeeds but h fails. I think we could do better!
At the moment we are not using the nat-solving framework, fanout/fanin expects the vector type to have already been solved, so this needs parallisation. Instead we should guess a vector type (of variables), and then yield until the length is solved to a constant.
The text was updated successfully, but these errors were encountered:
A neat way to do this would be to include a length in the syntax of fanout/fanin, which can be a constant, a hole (!), even an expression containing a hole (but no variables - the number of wires must be fixed for all values of all variables)
Fanout/fanin are checkable currently so the places they can be used is limited, but we could guess at the expected size using the nat-solving framework, they'd be much more useful!
e.g.
g
succeeds buth
fails. I think we could do better!At the moment we are not using the nat-solving framework, fanout/fanin expects the vector type to have already been solved, so this needs parallisation. Instead we should guess a vector type (of variables), and then yield until the length is solved to a constant.
The text was updated successfully, but these errors were encountered: