Closed GiggleLiu closed 6 years ago
First, for development related issue, please add a tag like: [Your Topic] in the very beginning of the title. And it would be better to use good first issue label for guideline issues.
IMHO, I still insist to have indexes stored in a block rather than gates. This is because the lack of inheriting in Julia, you cannot inherit members like Python, and this will cause multiple definitions of indexes. Try not to think about a Julia program like Python, and it's better to illustrate practical solution with a minimum working example (MWE) then you will find out this problem...
struct GateX
indexes
end
struct GateY
indexes
end
But it seems that packing separated indexes together would be a good solution for reduce memory in-contiguous and decrease cache missing.
As was discussed with @GiggleLiu , this is a rewrite of original blueprint folder to make it more trackable and clear. The Python
part is removed, mix python and julia up is quite weired... I will write another issue about parameter cache later. The details will be updated during the development.
A quantum register is an abstraction of quantum states processed by quantum circuits. It is an object that contains N
qubits, and can be reshaped, permuted.
mutable struct Register{T <: AbstractArray, N}
data::T
end
A register is actually a wave function in the form Psi(f, r, b)
, where
f
: concentrated dimensionsr
: remaining dimensionsb
: batched dimensionsSince, all types in julia is duck typed, we will firstly define this framework's structure by defining required functions.
type with:
apply!
: apply this gate-like object to a quantum register with certain parameters
-update!
: update this gate-like object (may contain parameters, like rotation gates) with some parameters will be a subtype of AbstractGate
. Besides, there will be several properties (some functions with only one input):
size
: get the size of this gate-like object (how many qubits it will apply to)The interface of block is the same with the interface of gates, which means blocks are a kind of gates. We will list extra interfaces in the future.
Basic gates are building material of circuits, e.g X, Y, Z, Rx, Ry, Rz, etc. It only use the interface of Gates.
The following types will use the block interface.
Block
are linear operators can be expanded on computational basis. It takes Block-List
as its member, thus can be viewed as a tree. It can use the interface of Gates. (which means a block can be treated as a gate)
A Concentrator will permute and expose the legs of a quantum register to other blocks/gates. For instance, given a register of 5 qubits and a Toffli gate on No. 1, 3, 5 qubit, by applying a concentrator of 1,3,5 to the register, No, 1, 3, 5 will be permuted and packed to be contiguous and exposed to next block/gate.
This is needs decision: use Focus or Concentrator as this block's name. I will use concentrator at the moment. Let's make this decision afterwards. However, I will list several reasons about why Concentrator
:
LeafBlock
is an abstract type for all blocks that do not have children. This may include:
Block
Focus
A wave function is a tensor of order-3, psi(f, r, b).
All blocks must be applied on the first (focused) dimension. Here, benchmark is needed to optimize the memory structure based.
Focus is a special "gate", users use it to change focused qubits to perform operations, like
Focus(4, 0, 1)
will change operation basis to lines (4, 0, 1) by index unraveling and permuting, i.e. for a 5-bit system, we will have psi((4, 0, 1), (2, 3), b). After this "gate", all blocks must be size 3, until another focus "gate" applied. Uses can useFocus()
to restore the state to default all focus mode.For un-blocked gates, we don't require the alignment of focused bits and gate operation space.