DISEÑO DEL CONTROLADOR PID PARA EL PÉNDULO

If we look look back at figure 2.7, we can see the essential building blocks for an implementation of Shor’s algorithm, or at least the quantum period finding part of the algorithm. We have developed the necessary modular exponentiation function, which acts exactly as is required taking the input registers from the state|ki ⊗ |~1i to the state _{|k, a}k_{modNi, where the value for N is the number to be factored,}

and the value a has been computed classically to be co-prime to N . We have also developed a unitary for the quantum Fourier transform on a register of qubits. So we can think of Shor’s algorithm as acting on a quantum register representing an integer, we can just lift the inverse QFT as a function that acts on a QInt.

qftI :: QInt → U

qftI (QInt i) = urev (qft i)

The last piece we need to define is also the simplest, and just applies the Hadamard rotation to each of the qubits in a QInt.

hadamards :: QInt _{→ U} hadamards (QInt [ ]) =_•

hadamards (QInt (q : qs)) = uhad q  hadamards (QInt qs)

The full unitary that represents the quantum part of Shor’s algorithm can now be constructed from these pieces, leading to definition given in figure 6.2.

To give the complete computation that represents the quantum part of Shor’s algorithm, we must ensure that the two QInt inputs are initialised to the values_|~0i and _{|~1i as required. The computation still takes N the number to be factorised,} and a corresponding a value (co-prime to N ) as its inputs, and the output is the value measured in the top register after the application of the unitary, this value

is a candidate for the period of the given modular exponentiation function. shor :: Int _{→ Int → QIO Int}

shor a N = do i0 _{← mkQ 0}

i1 _{← mkQ 1}

applyU (shorU i0 i1 a N ) measQ i0

To create the actual function which uses this quantum algorithm to compute the factors of an input integer can now be defined classically. As not every value of a gives rise to a solution, the algorithm is probabilistic. This means we can use a random number generator to pick candidates for a < N and use the euclidean algorithm to efficiently calculate the greatest common divisor of the two. In the case this is 1, we can use the value of a in the quantum part (if the greatest common divisor of a and N isn’t 1, then this is in fact a factor of N ). Once we have the period from the quantum part of the algorithm, we can do some classical post-processing to either find the factors of the input N , or have to repeat the quantum part of the algorithm again with a different value for the a candidate. The classical pre- and post-processing can easily be coded in Haskell to give the full factorisation function (factor :: Int _{→ QIO (Int, Int)). The full} implementation of such a function is given in the on-line source-code [Gre09], and we can already simulate a typical evaluation of running such a QIO computation. E.g. run (factor 15) gives (5, 3).

Chapter 7

Implementing QIO in Haskell

Having introduced the QIO API, and gone through some examples of quantum computation written in QIO, we can now go on to look at the implementation. More specifically, we look at how the run, runC , and sim functions are realised, concentrating on how measurement gives rise to the use of a monadic structure. It is these simulator functions, most specifically the run function, that give a corresponding semantics to our QIO computations.

In theory, if we had a quantum platform on which to run our QIO computa- tions then the run function would be much more efficient, but as it stands, we simulate the quantum behaviour using a classical random number generator. This classical simulation of quantum behaviour gives rise to large overheads in storing representations of quantum states (exponential in the number of qubits), and also of running our unitaries over such representations of quantum state (again expo- nential in the number of qubits).

To represent quantum states within a classical setting, we can follow the for- malism that a quantum state can be described in terms of a sum over all its base states and their corresponding complex amplitudes. This can be generalised in Haskell by defining a class of Heaps that represent the base states, and a cor- responding class of Vectors that represent a super-position of these base states, whereby each base state in the vector is assigned a complex amplitude. We have

designed our vector as a class dubbed VecEq, where all the primitive operations on the vectors are implemented such that they keep the overall state of the vector normalised. This normalisation equates to summing the amplitudes of any equal base states, and as such, the number of heap structures within the vector will never be more than the number of base states required to fully describe the corre- sponding quantum state. Building the normalisation directly into the vector class follows from the fact that only types with definable equality can be normalised (such as our implementation of heaps) in this way. It is nice to note here that the runC function, that can only simulate the classical subset of QIO, only needs a single heap structure to represent the entire classical state as would be expected.

7.1

Heaps

We define the Heap class by classEq h _{⇒ Heap h where}

initial :: h

update :: h → Qbit → Bool → h (?) :: h → Qbit → Maybe Bool forget :: h → Qbit → h

hswap :: h _{→ Qbit → Qbit → h}

hswap h x y = update (update h y (fromJust (h ? x ))) x (fromJust (h ? y)

So, any data structure that provides the necessary functions can be used as a heap structure for our implementation of QIO. Defining heaps in terms of a class means that the actual underlying implementation can be changed if a more efficient data structure is found (although, as we’ll see later, our use of Haskell’s Map data type is efficient for the task at hand). We can go on now to look now at what the functions in the Heap class actually represent.

heap structure, in which no qubits have yet been initialised. This element is called the initial element, as it represents the initial state of a heap before anything has occurred.

The update function is used to accommodate the application of a mkQbit prim- itive. Given a current heap structure, a reference to a qubit, and the Boolean state in which to initialise this qubit, the update function returns a new heap, in which the referenced qubit is assigned the given Boolean value. If the qubit isn’t already represented in the heap then it is added, as is the case when a mkQbit primitive occurs, but if the qubit is represented in the heap, then its value is updated to the given Boolean. This means that the update function can also be used when a rotation primitive occurs, as the only effect that a rotation can have on an indi- vidual base state is to apply the classical not function to one of the qubits in the base state.

A query function (?) must also be provided that simply returns the current value of the qubit being referenced. The Maybe monad is used here so that unini- tialised qubits can have the state Nothing, and not give rise to an undefined heap. If a Nothing value occurs during the evaluation of a computation, then a suit- able error must be thrown. The main case where an error of this sort occurs in practise is in a conditional where the control qubit appears as a variable in one of the branches. To accommodate the throwing of a run-time error whenever such a conditional occurs, the control qubit is temporarily forgotten from each base state using the provided forget function and hence, if it is used in one of the branches, the query function will fail, returning the error.

The hswap function returns the given heap, but with the values of its two argument qubits swapped around. This, in essence, swaps the positions of the two qubits with-in the heap, and is used whenever a swap primitive occurs in a QIO computation

As we previously mentioned, any data structure that provides an instance of the Heap class could be used as the basis for heaps in QIO. Our implementation makes

use of Haskell’s Map data type, which can be used to define a correspondence between Booleans and qubits in exactly the way our heaps require. The Map data type is an efficient implementation of key-value maps, and as such is a good candidate for our heaps. The operations for heaps can be directly translated into the primitive operations provided by the Map type.

typeHeapMap = Map.Map Qbit Bool

instanceHeap HeapMap where

initial = Map.empty

update h q b = Map.insert q b h h ? q = Map.lookup q h

forget h q = Map.delete q h

As the classical simulator function runC only requires a single heap structure to represent the entire state of the system, we can already define it by translating each of the QIO primitives into their corresponding primitives on the HeapMap data-type. In fact, the system must also keep track of the next available qubit so that a mkQbit primitive is guaranteed to return a reference to a new qubit, meaning that we can define a classical state by the type StateC as follows.

dataStateC = StateC _{{freeC :: Int, heap :: HeapMap }}

It is the pure nature of all these heap operations that also means we can give the runC classical simulator as a pure function.

We move on now to look at our vector structures that are used by the QIO simulator functions run and sim to represent fully quantum states. These func- tions translate the QIO primitives into the primitive functions available for our VecEq structures, which, as we’ll also see, in many cases corresponds to mapping the underlying heap primitives over every heap in the vector.