Documentation-friendly technical details

[pennylaneai]

Documentation-friendly technical details

[co9olguy]

Some updates to the docs have been done in af14a14, but these will still need to updated and polished further before release

[co9olguy]

Putting a note here so that we remember to include each of the employed gradient formulas on the conventions page

[mariaschuld]

I read through the documentation, and there is already a lot there.

[mariaschuld]

But what I don't understand is the concept of a quantum node as opposed to a quantum function.

[mariaschuld]

(Sorry, keep hitting the wrong enter key). Is it necessary to have both concepts? Aren't they somewhat the same, and we can use quantum function which controls a quantum device?

In short, this is confusing to the reader and I'm not sure we need it.

[co9olguy]

Yes, this is a discussion @josh146 and I have had previously. At some point, I had the same thoughts about these two similar concepts being redundant.

One distinction is that a quantum function is a just mathematical object which happens to be efficiently computable on a quantum device. On the other hand, the QNode is a particular abstraction, with fixed rules about how classical information is converted to quantum information, and back again.

[mariaschuld]

My suggestion is to rename quantum function to quantum node and use only one concept. What do you think @josh146 @co9olguy ?

Either way, it would be good to know for the manuscript how we frame this.

[josh146]

I'm very torn on the qfunc vs. qnode. On the one hand, I get the sort of abstraction Nathan mentions (a qfunc is a quantum function that can be run on a particular qnode, that is attached to a hardware device. One qfunc may be used to initialise multiple qnodes).

But, on the other hand, I am guilty of using qfunc/qnode interchangeably in my communication! Which indicates just how close a concept they are.

Using the QNode class initializer, this abstraction is easy to visualise:

def quantum_function(x):
  qm.RX(x, 0)
  return qm.expectation.Z(0)

qnode1 = QNode(quantum_function, dev1)
qnode2 = QNode(quantum_function, dev2)

This is not possible currently if you use the qfunc decorator, as this binds the following function to a QNode/device on function definition, and after that cannot be re-used (as there is no longer any access to the underlying qfunc).

I think we should keep both abstractions in the documentation. However, to avoid confusion, we should rename the decorator, since it essentially binds a qfunc to a qnode for the user.

Summary:

• A quantum function is any Python function that conforms to our restricted OpenQML qfunc definition; i.e. can only use qm.ops, one per line, and must return an expectation value.

• A qfunc can be bound to a QNode on a device, which is used to build the hybrid computational graph. The same qfunc can be used in multiple QNodes.

@mariaschuld and I were discussing alternate names for the decorator. Options are:

• @to_qnode/@toqnode
• @make_qnode/@makeqnode`
• @qnode (as opposed to the class QNode, which is in uppercase)
• @QNode.bind (make the decorator a class method of QNode)

My preference I think would be @qnode, thoughts?

[mariaschuld]

Seconded @qnode.

So I will use the concept of a qnode in the paper for now, and a quantum function is basically a wrapper for a variational or fixed circuit.

Can we somewhere write down the requirements of a quantum function so that the decorator works?

[co9olguy]

I've removed the conventions page, and shifted a lot of what it was meant to cover to other parts of the library (e.g., under Supported Operations). Some further points that were written there are no longer important (e.g., since we put expvals always at the end of a circuit, there is no need to discuss subtleties of non-commuting measurements)