Using pc for ps

[nikohansen]

With the option {'vv': {'pc for ps': whatever}}, the invariant pc evolution path is used for the sigma update. This however fails to increase the step-size due to the hsig mechanism (which prevents pc to strongly elongate axes in C as long as sigma is too small). That is, pc can in the current code not be reasonably used to update the step-size.

Resolution: for the time being, I will implement hsig to be 1 when 'pc for ps' is in 'vv' and hence pc is used for the sigma update. This is still suboptimal because it reintroduces the elongation problem (yet it is still much better than the current version).

This observation also strongly suggests that any practical implementation of CSA-CMA should have two evolution paths, even when the invariant inverse(sqrt(C)) x pc is used for the sigma update.

EDIT: we also have no decisive reasons to conclude that ps is not invariant.

[nikohansen]

It's not clear whether this is already implemented though the code seems to behave fairly reasonable now. hsig stays True even on the linear function, because the path norm computed in sigma_adapt.CMAAdaptSigmaBase.hsig does not pass the threshold when ps = es.sm.transform_inverse(es.pc) is used.

Related: pc2 is the path for diagonal decoding.

[nikohansen]

The option to activate using dot(inverse(C), pc) instead of ps is now 'CSA_invariant_path': True.

[nikohansen]

Comparing the step-size behavior on the sphere function with sigma0=2e-3. In particular, the axis ratio becomes around 20:
Invariant path:

Default: