Importing numpy about pennylane

[co9olguy]

Yes, importing should be consistent. While importing the vanilla of numpy should cause no issues if gradients are not involved, we will want users to get used to the pattern of importing the wrapped openqml version. For this reason, we should establish (and hold ourselves) to a solid standard of always importing the wrapped version.

[josh146]

The only place where it should be safe to import vanilla numpy is the plugins - as the plugins simply provide the device 'black box' that is used by autograd, nothing that takes place inside the plugins should affect the automatic differentiation.

[smite]

Like Josh said the plugins do not interact with autograd in any way, which is why I think they should import the standard numpy. The docs can make it clear that the users should always import numpy from openqml, but we also need to explain why (and when) this needs to be done.

[josh146]

Okay, let's formalize it as follows:

1. All files within OpenQML core must import NumPy from Autograd.
2. Users must import NumPy from OpenQML core.
3. Plugin developers import standard NumPy for their plugin, and OpenQML core NumPy for their examples.

[josh146]

@smite, since the submodules ops and expectation are part of OpenQML core, do you see any issues if we change the files contained to import NumPy from autograd?

[smite]

It's a bit complicated. In the case you mention importing autograd.numpy instead of numpy should be safe (but also unnecessary, since autograd should never see the Heisenberg matrices built using it) (they are used inside QNode and Operation, and as a hack in the SF plugin).

The downside of using autograd.numpy when it is not actually necessary is that it may in theory contain bugs that are not present in numpy proper.

One way to handle this is to use autograd.numpy inside OpenQML for now, and when we have a comprehensive arsenal of tests for different autograd use cases, start replacing instances of autograd.numpy with numpy inside OpenQML until a test breaks, thus identifying the places where it is actually required.

So I agree with points 2. and 3., and feel ambivalent towards 1. :)

[josh146]

A revised set of rules, in that case:

OpenQML Core/Base:

• All top level modules in OpenQML core must import NumPy from Autograd.
• All submodules in OpenQML core (such as ops and expectation) should import vanilla NumPy. This is assuming all submodules are 'black-boxes' to Autograd.

Users:

• Users must import NumPy from OpenQML core.

Plugin developers:

• Plugin developers import standard NumPy for their plugin, and OpenQML core NumPy for their examples.

[cgogolin]

The tests of openqml and openqml core should probably also import numpy from OpenQML core as the tests should mimic what is happening when the code us used by users? Looking into tests/default.py this currently does not seem to be the case...

[co9olguy]

Yes, that makes sense

[co9olguy]

I went through in 2da52ae and checked whether our imports follow the above rules, and made changes when they do not.

In the end:

1. I removed np altogether from variable.py (unused)
2. updated test_default_qubit.py and test_default_gaussian.py to import the openqml version of numpy
3. decided to leave the vanilla numpy version in both optimize.py (this will allow users to differentiate through gradient descent steps -- an atypical but not unheard of usage) and default.py (there numpy was only used in our custom assert statements