Suggestion for circuit entry syntax: bar notation

[pennylaneai]

Suggestion for circuit entry syntax: bar notation

[mariaschuld]

Seconded!

[josh146]

I'm in two minds about this. On the one hand, qm.Gate(p1, p2) | [wire1, wire2] is easier to parse/read, and is close to the style of Strawberry Fields and ProjectQ.

However, in the 'spirit'(?) of OpenQML, I would personally prefer to keep the syntax as 'pythonic' as we could, without overloading operators with a more commonly known use - a beginner or someone with a
a computer science/software engineering background would be more familiar with the 'bitwise or' behaviour of |, and would likely not recognise the pseudo-braket notation. By keeping everything as a function call and avoiding custom operator definitions, it is similar in style to NumPy np.func(..., axis=[1,2]), SciPy, TensorFlow, and OpenFermion (of.Hubbard(operators=...)).

(Avoiding the | syntax in OpenQML also helps keep the library quantum assembly language agnostic when working with other industry partners with their own quantum assembly language, otherwise it might appear we are co-opting Blackbird.)

An alternative third approach would be to use an operator that currently does not have any explicit action on standard Python objects. Since we are targeting only Python 3.5+ with OpenQML, we could use the @ operator, which invokes the __matmul__() method:

def circuit(weights):
    qm.Gate(weights) @ [wire1, wire2]

Another thing to be considered - assuming we choose to overload an operator, do we make explicit wire objects, analogous to the RegRef of Strawberry Fields? Or simply act the gate on a list of integers? I'm inclined to suggest just a list/tuple of integers in version 0.1, to avoid additional code complexity.

[smite]

I would use a list of ints to refer to subsystems/wires for simplicity, since there's no need for the extra functionality provided by the RegRefs.

I think I'd prefer | over the @ operator just because it avoids syntax proliferation (| is used not only in Blackbird but also in ProjectQ, so we cannot really be accused of pushing our own conventions, we joined an existing "standard"). I don't think operator overloading is a problem in itself, it's relatively common and easy to explain it in the docs. In Python __or__ is only defined for ints, so there shouldn't be much room for error.

Lastly and least importantly, since @ is matrix multiplication, semantically it may be a bit misleading since [w1, w2] does not represent a ket vector but a subsystem reference?

[co9olguy]

As @josh146 mentioned, the design philosophy of openqml is to be as close to numpy/tensorflow/scipy etc as possible, with the goal of making things more accessible for ML-only people to give it a shot.

We will stick with the standard pythonic way of calling ops, without overloading any operators