cdom or frontier doesn't work

[aisobran]

So I did a couple of checks, below is a graph of all the vectors encountered during the run:

The frontier for this run:

f:  [[0.8075993667375261, 3.292671758027631]]

If cdom is not working then the particles are picking the wrong best. Or the frontier being calculated is incorrect.

[aisobran]

Switching the call on the personal best cdom didn't have much of an affect.

[meneal]

Shit.

On Tuesday, December 1, 2015, Alexander Sobran notifications@github.com wrote:

Switching the call on the personal best cdom didn't have much of an affect.

— Reply to this email directly or view it on GitHub https://github.com/LambdaConglomerate/x9115lam/issues/37#issuecomment-161069156 .

[aisobran]

I'm not seeing how this paper: http://www.simonkuenzli.ch/docs/ZK04.pdf

Is the same thing as our implementation.

Also here's another paper, maybe with a clearer description, indicating the epsilon indicator used: http://ac.els-cdn.com/S1877050915022929/1-s2.0-S1877050915022929-main.pdf?_tid=78c3ecec-9865-11e5-8b6a-00000aacb35d&acdnat=1448999909_065a7dfd83950c632612ad4a95c9d6bb

[aisobran]

It seems like we should be calculating a fitness score compared to the whole frontier and then selecting the highest fitness scores and not a 1 to 1 comparison.

Seems pretty straight forward: I(x1, x2) = max for all obj : obj(x1) - obj(x2) FitScore(x1) = sum for all vectors (x2) on frontier: e^{-I(x1, x2)/k} Where k can be any scaling factor > 0

Then pick the best scores. This is much more computationally expensive then the current setup though.

[meneal]

So any ideas on what to use for k? Further on in the paper they suggest a fairly complex adaptive k calculation, but maybe we just use some small amount like 0.5 first and see what happens?

[aisobran]

The intuition would be 0 < k < 1.0 would make all difference's magnitudes larger. 1.0 might also be a possibility if we wanted to have no scaling.

[meneal]

I think this is complete at this point since we have a new working version of CDOM.