one hot encoding #918
one hot encoding #918
Conversation
| op_tree.append(cirq.X(b[0])) | ||
| for i in range(len(a)): | ||
| for j in range(2**i): | ||
| op_tree.append(TwoBitCSwap().on_registers(ctrl=a[i], x=b[j], y=b[2**i + j])) |
There was a problem hiding this comment.
You can use cirq.CSWAP here and the it'll automatically ge tconverted to TwoBitCSwap whenever the bloq-api is used due to the _cirq_gate_to_bloq logic.
There was a problem hiding this comment.
In fact, let's change the decomposition and build_call_graph to delegate to SwapWithZero bloq
|
|
||
|
|
||
| @attrs.frozen | ||
| class OneHotEncoding(GateWithRegisters): |
There was a problem hiding this comment.
Isn't this same as the SwapWithZero gate we already have?
There was a problem hiding this comment.
You can essentially write a one hot encoding bloq by doing an X(q[0]) and then call SwapWithZero with a as control and b as target.
The part after the first X gate is SwapWithZero bloq.
Also, SwapWithZero now supports N-dimensional registers so you can also do a one-hot for a multi dimensional input / output register. For example, if you have a 3d data where the input is 3 selection registers (a_x, a_y, a_z) and target is a 3D encoding where you would set target[x][y][z] = 1 when a_x = x, a_y = y and a_z = z; you can do this again by setting target[0][0][0] = 1 and calling a 3D swap-with-zero.
There was a problem hiding this comment.
There's no issue with swap with zero destroying the rest of the "b" register here? I've always been confused by when SwapWithZero is ok to use.
There was a problem hiding this comment.
The |B> register is assumed to be |0> in this case, so it doesn't matter how you permute it it will continue to be 0 everywhere except the x'th bit where you'll have a 1 since you swapped 0 <-> x .
The circuit after the first X gate is the same circuit as used for SwapWithZero
Simple bloq to implement a one-hot encoding. This will be used in a subroutine of QROM Inverse (PR forthcoming)