Allow vector patterns to be used in kernels #38
Conversation
| toLenConstr NP0 = pure $ Length 0 | ||
| toLenConstr (NP1Plus (NP2Times np)) = either (const (Right LengthOdd)) Right (toLenConstr np) |
There was a problem hiding this comment.
Ok...so....what does this do.....
- If
toLenConstr npreturns (Left error), we discard the error and returnpure LengthOdd - If
toLenConstr npreturns a Right value, we leave it unchanged
Is that right? (This is quite hard to follow)
If so, how about pure $ fromRight LengthOdd (toLenConstr np) ?
| err $ getVecErr tp (show ty) (show n) p' | ||
| Left (NumMatchFail _ _) -> case (toLenConstr p) of | ||
| Right p' -> err $ getVecErr tp (show ty) (show n) p' | ||
| Left p' -> err $ InternalError ("detectVecErrors: Unexpected pattern: " ++ show (toLenConstr p')) |
There was a problem hiding this comment.
What's this toLenConstr p'? This seems odd. So after toLenConstr has stripped away any outer (NP1Plus?) NPTwoTimess from the input p to give p', we then call it again to construct an error message? Is that right?
I'm hoping this should/could just be show p' in which case I have a different suggestion - how about moving the error-construction into toLenConstr (so it's :: NumPat -> Either Error LengthConstraint) and then using throwLeft here?
There was a problem hiding this comment.
Agreed, it's a bit hard to follow as is
| toLenConstr :: NumPat -> Checking LengthConstraint | ||
| -- Try to work out the length of a vector | ||
| -- We only want to know if the vector length is nil or a successor | ||
| toLenConstr :: NumPat -> Either NumPat (LengthConstraint) |
There was a problem hiding this comment.
Superfluous extra brackets here, at least
| @@ -0,0 +1,20 @@ | |||
| -- Create a "brickwork" state | |||
| -- Apply a parameterised unitary U to entangle every adjacent pair of qubits in a line architecture. | |||
There was a problem hiding this comment.
Eeek - skipping dependent types to ensure weights match in length, is this roughly just
brick(th ,- ths, U) = {q0 ,- q1 ,- qrest => let (q0,q1) = U(th)(q0,q1) in q0 ,- brick(ths, U)(q1 ,- rest)? (I.e. gate the first two qubits, then proceed "down the line" - what I thought was called a "ladder" architecture)?
If so then whilst a fun bit of list comprehensions they don't really do much useful (you're just riffling things apart and back together, and so on), right?
There was a problem hiding this comment.
Yes you're right, it's just a bit of fun that tests vector patterns are working in kernels 🙂
There was a problem hiding this comment.
Terminology-wise, I think this is called a brickwork pattern and a ladder is when everything else is sequentially entangled with 1 qubit
| @@ -121,6 +121,28 @@ kernelConstructors = M.fromList | |||
| (RPr ("tail", TVec (VApp (VInx (VS VZ)) B0) (VNum $ nVar (VInx VZ))) | |||
| (RPr ("head", VApp (VInx (VS VZ)) B0) R0))) | |||
| ]) | |||
| ,(CConcatEqEven, M.fromList | |||
| [(CVec, CArgs [VPVar, VPNum (NP2Times NPVar)] (Sy (Sy Zy)) | |||
| -- Star should be a TypeFor m forall m? | |||
There was a problem hiding this comment.
Not really sure I understand this comment...what happens if you replace the star with that TypeFor?
There was a problem hiding this comment.
I'll try and push something to clear this up
There was a problem hiding this comment.
My idea was that you could split on classical variables in the kernel, like
divConquer(n :: #, Vec({ Qubit -o Qubit }, n)) -> { Vec(Qubit, n) -o Vec(Qubit, n) }
divConquer(0, []) = { .. }
divConquer(doub(n), gs) = { qs0 =,= qs1 =>
let gs0 =,= gs1 = gs in divConquer(n, xs0)(gs0) =,= divConquer(n, gs1)(qs1)
}
but having just tried that, there are more blockers (gs isn't in scope in a kernel context anyway!) so I'll remove the comments.
Also, it'd be nice to be able to do this, as long as the pattern match is irrefutable... I guess we should come back to it after we have checking coverage of patterns
| Left (NumMatchFail _ _) -> do | ||
| p' <- toLenConstr p | ||
| err $ getVecErr tp (show ty) (show n) p' | ||
| Left (NumMatchFail _ _) -> case (toLenConstr p) of |
There was a problem hiding this comment.
So whilst continuing the slightly-hacked-in nature here and a better framework might be nice I don't think this is all that bad, certainly I'm not objecting to patching it in like this...
Vec)examples/brick.bratdetectVecErrorsto deal with the existence of more complicated vector tests than "0 or succ?". This is very much a bandage over a system that needs to be completely redone, but I hit up against this trying to write the example and it's errors should be slightly more informative now