Re-implement entropy_relative.

[hodgestar]

Description
Re-implement entropy_relative.

This function was implemented in March 2012, but then removed a month later. After some digging, it appears that the reason the function was removed is that it assumed the eigenvectors of the density matrices were identical (and in the same order).

After some reading of Nielsen & Chuang, I have re-implemented it to address the issue.

Still todo

• Update the documentation.
• Add an example to an example notebook.
• Add some tests for specific cases where we know what the answer should be.
• Stretch goal: Vectorize the calculation of P_ij and the rest of the loop as much as we can (but let's make sure the answers are correct first).

Changelog
Re-implement entropy_relative which returns the quantum relative entropy between two density matrices.

[coveralls]

Coverage increased (+0.6%) to 64.928% when pulling c254091 on hodgestar:feature/re-implement-relative-entropy into 6845908 on qutip:master.

[jakelishman]

Thanks for both finding this and fixing it! I have a suspicion there was an old issue or mailing list message that was asking for some quantity derived from relative entropy as well, so this is definitely good to get working.

[jakelishman]

Oh, I just noticed the comment at the top about vectorisation of the calculation of P. I could be wrong, but I think P = np.abs(np.inner(rvecs, np.conj(svecs)))**2 gets you there.

[hodgestar]

The intermittently failing test seems unrelated and is test_usage_in_solvers[mesolve-complex-spline,string].

[hodgestar]

@jakelishman @Ericgig @Albantakis Ready for a second round of review, I think!

[hodgestar]

I'm didn't find an obvious notebook in qutip-notebooks to add an example to. Not sure how we usually proceed in such cases -- skip having an example in a notebook? Make a new notebook?

[jakelishman]

Looking good. For notebooks, we've historically not been good at updating them, I think. For a single, clearly defined function, probably just adding an Examples section in the docstring might be more appropriate? I'm not entirely sure.

[jakelishman]

We can't use it without swapping how we handle the logarithms, but if it's useful in the future, scipy has scipy.special.xlogy that specifically handles 0 ln(0) := 0.

[hodgestar]

I'm okay with not involving scipy.special.xlogy for now -- it's another thing for readers of the code to think about and I'm not sure where the bottlenecks in the current code are or how much anyone cares about performance (my guess is that finding the eigenvalues is the slowest step now).

[jakelishman]

Oh yeah, no need to put it in now. Now that everything's vectorised, I'd be surprised if the dominant time factor wasn't the eigenstate calculation.

[hodgestar]

@jakelishman I added an example to the docstring.

[jakelishman]

Nice, and it's all rendered correctly in the HTML documentation