Core Components

Once the basic algorithm for simulating a circuit was decided upon the next step was to design a simulator around the algorithm. I had previously worked at Microsoft on ActiveMovie where the rendering of multimedia files is accomplished by passing data between filters. The filters expose input and output pins and connections are made between them. File readers are special filters that pump data in to the system. The data leaves the system through filters which represent rendering devices. The whole was then a termed a filter graph. This design is directly analogous to a quantum circuit with gates instead of filters and circuits instead of filter graphs. Data enters the quantum circuit through special gates, which I term sources, and leaves through sinks.

While the topology of a quantum circuit bears a certain similarity with ActiveMovie the design and implementation differs greatly. I think that it would be possible to implement a quantum circuit using ActiveMovie but I do not see any reason why anybody would want to do so. The job of ActiveMovie is to provide the timely arrival of multimedia packets, allow graceful degradation where resource requirements cannot be met by the host computer and to allow developers the freedom to change part of implementation of playing a multimedia file without having to change the whole. These goals bear no resemblance to the goals in simulating a quantum circuit. Therefore using ActiveMovie would have offered no advantage in developing the simulator and would have undoubtedly proved to be a large hindrance. With this in mind I quickly decided to avoid ActiveMovie and design and implement a set of classes for the sole purpose of simulating a quantum circuit.

Immediately the topology of a quantum circuit leads to the suggestions of classes for pins, gates and circuits. The pins may be input pins or output pins, which suggests a derivation of these from a base pin implementation, and may only be connected to a pin of the opposite type. The gates may be sources, sinks or a gate that takes an input and provides an output. Each gate will hold a list of input and output pins. The circuit would hold a list of gates.

It was necessary to decide what degree of the simulation would be carried out by the circuits, gates and pins and what degree external classes and methods would carry out processing. In other words I needed to decide whether the circuit and its components would be dumb or clever. A dumb circuit would just hold the information required to reconstruct the topology of circuit. A clever circuit would hold the topology and have enough knowledge to perform simulation itself.

I think that it is generally better to have a large number of small co-operating classes than it is to have a small number of classes that carry out many varied tasks. Therefore I decided to have dumb circuits in order to lessen the amount of functionality which would have to be built in to any one class. This meant that I needed a class to perform the simulation. I dubbed the simulation class 'the Metaverse', as it would appear that its job is to control the evolution of the circuit in many universes.

The class CMetaverse provides the following functionality.

• The ability to perform a simulation on a given circuit. An overview of the algorithms used is given later.
• The ability to input and output data for the simulations.

The class CCircuit provides the following functionality.

• Add gates to the circuit.
• Create predefined test circuits.
• Provide statistics on the size of the circuit, its number of gates, etc.
• Load a circuit from a given input stream.
• Connect a specified input pin to a certain bit in the circuit.

The class hierarchy for gates is shown below.

_{Figure 15}

The base class for gates is the class CGate which provides a default implementation. It provides a number of methods that can perform the tasks listed below. Derived gates are able to override the implementation of any of these functions.

• Returning the number of input and output pins.
• Returning a specific input or output pin.
• Given an input to the gate return the output.
• Return the name of the gate and the circuit to which we belong.

From CGate we then derive three more class - CInputOutputGate, CSinkGate and CSourceGate. CInputOutputGate provides a default implementation for gates with more than one input and output pin. (Remember from the background section that quantum gates must have an equal number of input and output gates). From CInputOutputGate two gates were derived for test purposes - CFlipGate and CSquareRootNOT. The latter performs the square root of not function on a single input bit, the former performs the function on one of its two input pins only if its other input pin has the value 1.

CSinkGate provides an implementation for sinks. Initially designed to cater for any number of input pins I later revised this to allow only one input pin in order to ease the implementation of certain simulator methods. CSourceGate allows data to enter the system. It's derivation, CStaticSource exposes an output bit whose value is set at creation at 0 or 1. CRandomisedSource exposes an output bit whose value is randomly set at creation at 0 or 1.

The implementation of CSuperpositionedSource was later removed. The gate is functionally equivalent to a CStaticSource followed by a square root of not gate, i.e. the output is an equal superposition of 0 and 1. Again, allowing for such a 'special' gate created technical difficulties in other areas of the program. It was introduced due to an error in my thinking (see the later section entitled Original Design Error) where I thought that such a gate would greatly reduce the resources required by the simulation. Once the error was recognised I decided that the CSuperpositionedSource added little to the simulation while making the code less understandable and harder to maintain.

The class hierarchy for pins is shown below.

_{Figure 16}

The abstract base pin class, CPin, provides the following default functionality.

• Requires a derived class to provide the direction of the pin.
• Return the pin to whom it is connected, if any.
• Perform a connection to another pin.
• Return the parent gate of this pin.

From CPin we derive CInputPin and COutputPin. These classes simply specify the direction of the pin. The only purpose of having a direction on a pin is to ensure that we do not attempt to connect the output of two gates together. The pin classes hold the state information for connections and do not actually perform any work.