Discrepancy: paxes vs axes

Hello, I’m trying to learn more about this code and I keep scratching my head over how axes and paxes are used within the bounding algorithms and the sampling algorithms.

For example, in the ellipsoidal code, the axes are labeled as the “transformation axes” of the ellipsoid and are the Cholesky decomposition of the covariance matrix. Also here, paxes are labeled as the principle axes and then describe how they should be used for transforming between the unit hyper-cube and the prior volume.

Given this, I assume that methods like the random-walk (rwalk) implementation would use paxes to generate proposals, yet the code fed into it uses axes (many snippets of “if method in [‘rwalk’,…] return ell.axes”. Upon inspecting the nestle codebase and some of my own code, the appropriate solution is to use paxes as they are described in the bounding constraint constructors.

Is this is a bug or is this a lapse in my understanding?

[joshspeagle]

If I’m remembering correctly, there was some point during development where doing the Cholesky decomposition was useful for checking stability. Since you get the matrices for free, I think I just started using them as a result. I’m sure there were other reasons that I could back out looking through old commits, but that’s all I got off the top of my head.

And no problem! Happy to try and help. If you have any other questions, happy to answer them here. Feel free to close this issue whenever you’re satisfied.

[mileslucas]

That seems reasonable (and I could check with monte-carlo easily enough), though it begs the question: if you can slice and sample using paxes why carry around axes at all?

Thanks for having this commentary, too, I really appreciate it!