qpp::measure causes Eigen assert

[antoine-bussy]

Hi,

qpp::measure causes the following Eigen assert:

/usr/include/eigen3/Eigen/src/Core/PlainObjectBase.h:366:
void Eigen::PlainObjectBase<Derived>::resizeLike(const Eigen::EigenBase<OtherDerived>&) 
[with OtherDerived = Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<std::complex<double> >, 
Eigen::Matrix<std::complex<double>, -1, -1> >; 
Derived = Eigen::Matrix<std::complex<double>, 4, 1>]: Assertion `other.rows() == 1 || other.cols() == 1' failed.

I've reproduced it with the following test: antoine-bussy@b873e7e
and fixed it this way: antoine-bussy@36b0343

The bug is that outstates is being initialized with square matrices, even though it stores vectors in this use case.

Do you want me to submit a PR?

[vsoftco]

Thanks! Good catch. I'll incorporate the fix into the current dev branch (where I'm fixing the other issue), so no need for a PR for this one.

[vsoftco]

@antoine-bussy Fixed on dev branch. In fact, there's no need for that resize second argument, so simply defining std::vector<expr_t<Derived>> outstates(Ks.size()); suffices.

[antoine-bussy]

Thanks!

I uncovered another "bug" stemming from my PR #110.
Let's take the case of qpp::measure

1. Before the PR, qpp::measure accepted any Eigen matrix as input, and returned outstates as cmat
2. After the PR, qpp::measure accepted any Eigen matrix as input, and returned outstates with the same type as the input

Point 2 is fine as long as users stick to ket and cmat. It doesn't work anymore when the input is a fixed-size vector and destructive = true, since outstates don't have the same dimension as the input anymore. So it's more a possibility of misuse rather than a bug.
I can think of 3 possible "fixes":

1. Leave the code as is, users should be using ket and cmat
2. Protect the code with checks (e.g. static_assert)
3. Define outstates to be ket or cmat when the input is a fixed-size vector or matrix, like this https://github.com/antoine-bussy/qpp/blob/62b937ebe2b7027a5d1fb3ad572fdaad86734e55/include/types.hpp#L107-L144

@vsoftco What do you think?

[vsoftco]

@antoine-bussy Yes, I bumped into that (when testing your code). I think the latest solution is the most straightforward, and least intrusive.