merge Pauli gates for composite blocks

[Roger-luo]

merge Pauli gates for composite blocks

[Roger-luo]

Fortunately, our simplifier just works for the follow composite blocks (multi-qubits blocks contains single qubits Paulis)

julia> using YaoBlocks

julia> g = chain(2, kron(X, chain(X, Y)), control(2, 1=>X))
nqubits: 2, datatype: Complex{Float64}
chain
├─ kron
│  ├─ 1=>X gate
│  └─ 2=>chain
│     ├─ X gate
│     └─ Y gate
└─ control(2)
   └─ (1,)X gate


julia> simplify(g)
nqubits: 2, datatype: Complex{Float64}
prod
├─ control(2)
│  └─ (1,)X gate
└─ kron
   ├─ 1=>X gate
   └─ 2=>[-im] Z gate

I think next step is to define simplification rules for Cliffords, which will work for multi-qubits circuit in general. Probably this part should be moved to another package in the future, but whoever interested in this feature could start trying YaoBlocks with it now.

[GiggleLiu]

Merging pauli gates might be a useful feature.
But please don't use prod in unitary evolutions, this example just shows how terrible it is.

[Roger-luo]

This is useful and this is not related to this issue, see #9. The point to use prod here is just because it's easy to implement. I think eventually these things should be move to a single package for symbolic computing and circuit optimization. But we can use it for now.

[GiggleLiu]

it's easy to implement

Not implementing it would be better. For preventing potential errors.

[Roger-luo]

I don't see any potential errors, you can't construct/desctruct a Prod without operators.

[Roger-luo]

The point of #9 is when someone really hit something, it's never too late to make things work. We can't make everything work with one go.

[GiggleLiu]

when someone really hit something.

I think we both agreed that our development should be demand-driven.
Then, we should remove the Prod, keep the issue and wait for the feature requests. Prod is a replaceable structure, it is almost parallel to chain in functionality.

[Roger-luo]

It's something required for simplify for now, if this is removed, it won't work at all. I don't think remove functionality is a good idea. The point is we could remove Prod after implementation a pass for chain.

It's not something breaking the API, since Prod is just a temporary representation of * and Prod. And not something preventing things not to work.

[GiggleLiu]

There should not be too much overlap between Prod and ChainBlock, make it possible or remove Prod.

remove Prod after implementation a pass for chain

Don't get this point.

[Roger-luo]

I can just remove Chain's pass so simplify only works for Prod. And add it back when we have time to implement one for Chain.

[GiggleLiu]

ok, then please also polish the printing

instead of

prod
|- X gate
|- Y gate

print X*Y.

[Roger-luo]

This printing should be a bug. I'll have a look when I'm back.

Ok now */prod strictly corresponding to Prod, nothing else will create a Prod node implicitly. (It's just one line anyway)

[Roger-luo]

@GiggleLiu The printing is correct:

julia> X  * Y
nqubits: 1, datatype: Complex{Float64}
prod
├─ X gate
└─ Y gate

I don't get

prod
|- X gate
|- Y gate

[GiggleLiu]

I mean, X*Y would be better.

[Roger-luo]

But this will mess up the following

control(2, 1, 2=>X) * kron(X, Y)

which make sense for simplification and basis, etc. (they are Cliffords) and I don't think it's trivial to workaround that. I'd like to keep what it is now, at least it is readable (it won't be readable at all for composite block in a single line).

X * Y only works for primitive blocks, since you don't need multiple lines.

[GiggleLiu]

you are right.