Update "index" "Overview" and "NetQASM" documentation

Author: dieriver

README.md

@@ -69,8 +69,25 @@ After installing the Operating System on the virtual machine, please continue th
 the virtual machine using the Linux instructions as mentioned above.
 
 
-Documentation
--------------
+## Tests
+
+There are 2 sets of tests: quick and slow ones. To ease the execution, the `Makefile` provides two targets:
+* `tests`: This target only run the quick tests.
+* `tests_all`: This target runs quick and slow tests.
+
+To run a test target, simply invoke it with make:
+```shell
+make tests
+```
+
+or:
+```shell
+make tests_all
+```
+
+
+## Documentation
+
 
 Documentation and examples are explained in the HTML documentation 
 https://softwarequtech.github.io/SimulaQron/html/index.html

docs/NetQASM.rst

@@ -17,13 +17,13 @@ everything you need::
 Core concepts
 --------------
 
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 NetQASMConnection
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 
-Your connection to the **local quantum backend** (SimulaQron's virtual quantum node). This is *not* a connection
-to another party — it is how your node talks to its local simulated quantum hardware. All qubit operations are
-queued through this connection.
+This objects represent your connection to the **local quantum backend** (SimulaQron's virtual quantum node).
+This is *not* a connection to another party — it is how your node talks to its local simulated quantum hardware.
+All qubit operations are queued through this connection.
 
 Create it once, use it throughout your program, and close it at the end::
 
@@ -36,11 +36,14 @@ Create it once, use it throughout your program, and close it at the end::
 
 If your program uses EPR pairs, pass the EPR sockets at creation time::
 
+    from netqasm.sdk import EPRSocket
+
+    epr_socket = EPRSocket("Bob")
     conn = NetQASMConnection("Alice", epr_sockets=[epr_socket])
 
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^
 Qubit
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^
 
 A qubit allocated on the local quantum backend. Pass the connection so the backend knows where to allocate it::
 
@@ -54,9 +57,9 @@ A qubit allocated on the local quantum backend. Pass the connection so the backe
 
 Gates are **queued** — nothing executes until you call ``flush()``.
 
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^
 EPRSocket
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^
 
 Used to create or receive entangled qubit pairs with a remote node::
 
@@ -70,9 +73,9 @@ Used to create or receive entangled qubit pairs with a remote node::
     epr_socket = EPRSocket("Alice")
     epr = epr_socket.recv_keep()[0]
 
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^
 flush()
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^
 
 The **sync point** that executes all queued quantum operations and makes measurement results available.
 Before ``flush()``, measurement results are just futures/promises. After ``flush()``, you can read them
@@ -93,9 +96,9 @@ You can call ``flush()`` multiple times on the same connection. This enables **m
 
 See the mid-circuit logic example in `Examples <Examples.rst>`_ for a full demonstration.
 
------------------------
+---------------
 Minimal example
------------------------
+---------------
 
 A single-node program that creates a qubit, applies a Hadamard gate, and measures::
 
@@ -110,9 +113,9 @@ A single-node program that creates a qubit, applies a Hadamard gate, and measure
     print("Measurement outcome:", int(m))
     conn.close()
 
------------------------
+--------------------
 Two-node EPR example
------------------------
+--------------------
 
 Alice and Bob generate an EPR pair and each measure their qubit to get correlated random numbers.
 
@@ -138,9 +141,9 @@ Alice and Bob generate an EPR pair and each measure their qubit to get correlate
 
 Both sides will print the same random number (0 or 1), demonstrating quantum correlation.
 
---------------------------
+-----------------------
 Classical communication
---------------------------
+-----------------------
 
 For exchanging classical messages between nodes (e.g. measurement outcomes for teleportation corrections),
 SimulaQron provides ``SimulaQronClassicalClient`` and ``SimulaQronClassicalServer``.

docs/Overview.rst

@@ -76,7 +76,7 @@ deal with this backend simulation.
 
 Nevertheless, as a guide to the backend, it consists of three essential components:
 
-* quantumEngine - There are currenlty three different quantumEngines implemented: Using `QuTip <http://qutip.org/>`_
+* quantumEngine - There are currently three different quantumEngines implemented: Using `QuTip <http://qutip.org/>`_
     and mixed state, using `Project Q <https://projectq.ch/>`_ and pure states and finally using stabilizer formalism.
     This corresponds to one quantum register full of qubits across which gates can be performed. Should you wish to
     use a different backend, you may wish to add a different engine.
@@ -170,7 +170,8 @@ Automated tests
 ^^^^^^^^^^^^^^^
 
 There are number of automated tests that test many (but not all) of the features of SimulaQron and the NetQASM interface.
-See `Getting Started <GettingStarted.rst>`_ for how to run these.
+To run these tests, you need to clone the SimulaQron `GitHub repository <https://github.com/SoftwareQuTech/SimulaQron>`_,
+and follow the ``README.md`` file to install and run the tests.
 Some of the automated tests use quantum tomography and are thus inherently probabilistic.
 Therefore if you see that one of these fails, you can try to run the test again and see if it is consistent.
 If the tests are to slow on your computer you can also run the short version, which skips the quantum tomography tests.

docs/index.rst

@@ -13,7 +13,7 @@ Key features
 
 * **Distributed quantum internet simulation** — install a local simulation program on each computer, or run all nodes
   on a single machine
-* **Three simulation backends** — stabilizer formalism (default, efficient), `QuTip <http://qutip.org/>`_ (mixed
+* **Three simulation backends** — stabilizer formalism (efficient), `QuTip <http://qutip.org/>`_ (default, mixed
   state), and `ProjectQ <https://projectq.ch/>`_ (pure state)
 * **Two programming interfaces** — the NetQASM SDK (recommended) and a native Twisted mode for low-level access
 * **Configurable network topologies** — complete, ring, path, random tree, or custom topologies