Gates and channels don't check that their arguments are real numbers (sf 0.9)

[ziofil]

Gates and channels don't check that their arguments are real numbers.
Example:

with engine:
    Dgate(1+1j) | mode

This keeps running without raising an exception.

[josh146]

Hi @ziofil, this is actually intentional behaviour, but specific to the Dgate. With the displacement gate in particular, it is common to consider the alpha parameter in Cartesian form. However, in other applications (such as optimizing its parameters using TensorFlow), it is easier to consider it in polar form.

Since we can make use of Python's duck typing, we tried to support both forms with the following docstring:

i.e., a can be a complex number, or alternatively you may provide a as a real number and also phi for the complex phase.

[ziofil]

Oh! Sorry for not spotting that earlier... bad example 😆
However, also LossChannel accepts a complex parameter without complaining. Is that also intended behaviour?

[josh146]

Early on, we had a discussion internally on how much input validation we wanted to do in Strawberry Fields. We definitely did more input validation in places like the engine (i.e., number of qumodes, etc), but decided to be less stringent for the gates. This was for several reasons:

1. Too much input validation can become unwieldy, complicates the program, and leads to code duplication, and may unintentionally cut off the user from some valid input edge cases

2. We decided to take the approach to 'trust the user', that they would read the docstrings, and apply the operations as written, similar to the approach taken by NumPy.

Although, in this case, since the LossChannel unintentionally seems to work fine with complex parameters, perhaps this is something we should validate against? Unless there is a case (I'm very doubtful) where a complex loss parameter makes sense!