implemented a possibility of mixing measurement operators and callback functions in e_ops list

[marekyggdrasil]

Description

I propose to make it possible to have callable functions inside of the e_ops list, not only operators. This becomes useful if we want to measure energy or if we want to have time-dependent measurements just like time-dependent Hamiltonian.

Changes are pretty straightforwards, mostly making sure types match. Important design choice is, if measurement is not an operator but a function, the data type is complex by default (to handle the general case).

Feedback and suggestions for changes are welcome. I will be happy to contribute more!

Related issues or PRs

Suggested in #1238

Changelog

1. Modified mesolve and sesolve objects to handle callable function inside of the e_ops list.
2. Prepared solver to create empty measured data if list of e_ops contains a callable function.
3. Modified one of the high level tests, test_compatibility_with_solver by adding an additional measurement which is not an operator but a lambda expression.

[coveralls]

Coverage increased (+0.1%) to 65.875% when pulling 6387799 on marekyggdrasil:master into bd773e6 on qutip:master.

[hodgestar]

@marekyggdrasil Thanks Marek. This was already implemented for QuTiP 5 in #1462. I think there is still some value in having this implemented for 4.7 though. I'm going to leave the review for @Ericgig -- the changes look good and fairly straightforward to me, but it would also be good to be sure that they fit in with the plans for version 5.

[marekyggdrasil]

Thank you @hodgestar ! I will also fix the PEP8 problem.

[Ericgig]

Hi @marekyggdrasil, thank you for your contribution.
This approach look good.

[Ericgig]

I rewrote the doc in a more verbose way and removed mention of QobjEvo in sesolve and mesolve's e_ops where they are not supported.

[marekyggdrasil]

@Ericgig any tips how to locally run pycodestyle linter so that it follows same settings as codeclimate? When I run it locally it show way more warnings than codeclimate, seems a lot more restrictive. I'm sure some sort of configuration is missing. I checked the contribution guide but this particular matter is not detailed. If you explain how to run linter locally I would be happy to also update the docs and document it for the future contributors.

[Ericgig]

No, we use default setting for codeclimat's pep8 so I can't really tell you how to reproduce them with pycodestyle.
codeclimat will only complain about issues introduced in the PR, not the whole file.
The issues that it finds are mostly lines too longs in the doc-string suggestions I made. If you can just clean that up with a proper editor, it should pass the codeclimat check.

[Ericgig]

@marekyggdrasil could you fix the codeclimate check before a new review.

[marekyggdrasil]

@Ericgig sure I will be happy to fix the linting errors, I seem to have missed your previous message about codeclimate, sorry about that.

[Ericgig]

I think I found what you want: git diff master | pycodestyle --diff. It run the linter on the diff between the branches. So it should see the same issues as codeclimat.
Everything looks good with your last commit, I am just waiting for test to finish to review.

[Ericgig]

Merged!
Thank you Marek for your contribution.

[marekyggdrasil]

It's my pleasure, @Ericgig !