Thank you for implementing this. Can you please say more about why you emulated ndarray::Array::asEigen such that asEigen(array) returns a Matrix map and ndarray::asEigen<Eigen::ArrayXpr>(array) returns an Array map.

I had been hoping for asEigenArray and asEigenMatrix for two reasons:

• It makes the code easier to read and more obvious (it's not clear to me why asEigen would return a Matrix instead of an Array)
• It makes it a bit easier to spot old LSST code that needs conversion

On the other hand if one can request more than just Matrix and Array then the flexibility may be helpful and we do have a few other asEigen functions that will confuse conversion regardless of what we call this.

There have a been a few occasions where I've wanted to write code that works with either Array or Matrix objects, and I hate having to duplicate that code rather than just templating it.  I wouldn't object to also having asEigenMatrix and asEigenArray (or just the latter), but I'd like to keep the current new signatures, too.

Russell Owen, as you're doing most of the work on this, you might as well take it back. You may also want to take a look at whether the Epic is right - either it isn't, or the Epic's description has the wrong cycle.

Jim Bosch did the heavy lifting adding the free functions asEigen but suggested I take it back due to doing some of the work, so I did so.

As to the epic: it is the one John Swinbank suggests we use. Perhaps the epic needs updating.

(Just to be clear, I think that was a miscommunication — the correct epic for this work is DM-14447).

I updated the tarball, tweaked the build to build EigenView (since it will take a bit of work on our wrappers to switch to pybind11's Eigen header) and removed an outdated patch.