qat.qpus.PyLinalg

The quantum state is stored as an ndarray of shape \(\left(2,...,2\right)\), with one 2-valued index per qubit:

\[\vert\psi\rangle = \sum_{i_{1},\dots,i_{N}\in \{0,1\}^{N}} a_{i_{1} \dots i_{N}}|i_{1} \dots i_{N}\rangle\]

where \(|i_{1}\dots i_{N}\rangle\) represents a computational basis state.

Quantum gates are also manipulated as ndarrays, with \(2\times \text{arity}\) 2-valued indices. Half of the indices are input indices and the other half output indices.

Applying a gate consists in contracting the input indices with the indices corresponding to the qubits on which the gate is applied:

../../../images/tensordot.png

The main point of using ndarrays is that this operation can be easily written with the np.tensordot function.

Within myQLM, this simulator is contained in the qat.pylinalg module.

Quantum Processing Unit

This high-level class wrapping the simulator follows the convention of the qat.qpus.QPUHandler structure.

class qat.qpus.PyLinalg

Simple linalg simulator plugin.

Inherits serve() and submit() method from qat.qpus.QPUHandler Only the submit_job() method is simulator-specific and defined here.

serve(port, host_ip='localhost', server_type=None, ssl_cert: Optional[str] = None, ssl_key: Optional[str] = None, ssl_ca: Optional[str] = None)

Runs the QPU inside a server, optionally with the SSL protocol.

Parameters

  • port (int) – the port on which to listen

  • host_ip (str) – the url on which to publish the API. Optional. Defaults to ‘localhost’.

  • server_type (str, optional) –

    type of server. The different types of server are:

    • ”simple”: single-thread server, accepts one connection at a time (default server type)

    • ”threaded”: multi-thread server, each connection starts a new thread

    • ”pool”: multi-thread server, each connection runs in a thread, with a maximum of 10 running threads

    • ”fork”: multi-process server, each connection runs in a new process

  • ssl_cert (str, optional) – path to the server SSL certificate (mandatory for SSL) Default: None

  • ssl_key (str, optional) – path to the server SSL key (mandatory for SSL) Default: None

  • ssl_ca (str, optional) – path to the server SSL certificate authority (only serves requests with signed certificates) Default: None

submit(batch: Batch, meta_data: Optional[dict] = None) → BatchResult

Executes a batch of jobs and returns the corresponding list of Results.

Parameters

batch (Batch) – a batch of jobs. If a single job is provided, the job is embedded into a Batch, executed, and the first result is returned.

Returns

a batch result

Return type

(BatchResult)

submit_job(job)

Returns a Result structure corresponding to the execution of a Job

Parameters

job (Job) – the job to execute

Returns

the result

Return type

Result

Note

The submit_job() method above basically consists of two imbricated if statements.

The first one looks at the type attribute of the job, which can take two values:

  • OBSERVABLE (cf. ProcessingType): the job consists in evaluating an observable at the end of the circuit. Currently, the attribute nbshots has no effect if the type is OBSERVABLE

  • SAMPLING (cf. ProcessingType): the job consists in sampling the output probability distribution of the quantum circuit. This is where the second if loop comes in, depending on the number of shots which is asked (job.nbshots):

    • if nbshots=0 then the simulator/quantum-processor returns the best it can do. In our case, of a linear-algebra-based simulator, this is the entire probability distribution.

    • else, the simulator samples the output probability distribution nbshots times.