Operator_map and observable_map

[pennylaneai]

Operator_map and observable_map

[co9olguy]

Status on this? Why was it closed? Has it already been implemented?

[josh146]

Ah, it was closed by accident. I was attempting to delete it because I messed up the title, and didn't want anyone seeing my mistake 😬

I have been playing around with having operator_map and observable_map as class attributes, and here are my thoughts:

1. For the ProjectQ and SF plugins, having an operator_map is really natural, as there is a 1-to-1 mapping between OpenQML operations and plugin operations.

2. On the other hand, an expectation map is not as natural; for example, in SF, the expectation operations map into SF state methods. One solution would be to create functions within the plugin to allow for this:

def Homodyne(par):
    return lambda state, wires: state.quad_expectation(wires, *par)

or something to that effect. These can then be used directly in observable_map.

Other plugins may have the same issue with operator_map, resulting in potential spaghetti code. On the other hand, enforcing the use of operator_map and observable_map makes the plugin API cleaner - the plugin developer no longer needs to worry about raising DeviceError if an operation/expectation is not supported, as OpenQML will know by querying the map attributes.

[co9olguy]

Looks ok to me.

We won't be able to make too many assumptions about the form of the backends if we want to support as many as possible. It's the job of the plugins to map openqml operators/observables to the relevant backend commands. Sometimes this will use a simple dictionary to map between the two, but in other cases, there might be a few more lines of code (as you illustrated in the lambda example). This is ok

[josh146]

Okay, I'll finish this change for the SF and default plugins, and merge tonight.

[josh146]

Done in #48 and #49