Fix SBX prob_bin parameter behavior

[lukepmccombs]

The prob_bin parameter for SBX behaves incorrectly, where one child is preferentially distributed about the higher values of the parents and the other the lower values. This PR fixes the behavior so prob_bin controls similarity to the parents instead.

Examples for prob_bin=0.25 with 3 variables in [-2, 2]
Parent 1 is [-1, 1, -1]
Parent 2 is [1, -1, 1]

Before the fix:

After the fix:

[blankjul]

The current implementation follows the paper that has been published by Dr. Deb. One issue with the proposed modification could be when their are dependencies across variables.
Just curious, have you tested your crossover and it performed better?

[lukepmccombs]

The issue is that the current implementation introduces new dependencies caused by vectorizing with numpy that I believe were unintentional.

I put together the following experiment to test the performance difference:
https://gist.github.com/lukepmccombs/687158986e0ccfb4e42c65c55f03753b
It measures performance on ZDT6 and the same problem with the parameter landscape alternately flipped for prob_bin = 0.5 and 0.01. The expected behavior should be that the landscape change doesn't effect performance, and that the change in performance due to prob_bin should be roughly the same for either problem.

Running it on main, I get the following results:

ZDT6                   prob_bin: 0.50   95% hv: 0.111553, 0.118944
ZDT6                   prob_bin: 0.01   95% hv: 0.310344, 0.314175    <- Optimal parameters are mostly zeros, so benefited by the bias
AlternatingZDT6        prob_bin: 0.50   95% hv: 0.110402, 0.118404
AlternatingZDT6        prob_bin: 0.01   95% hv: 0.052720, 0.058567    <- Optimal parameters are half zeros, half ones, so hindered by the bias

And on my fork's develop it performs as expected with a not-insignificant performance bump:

ZDT6                   prob_bin: 0.50   95% hv: 0.142128, 0.149016
ZDT6                   prob_bin: 0.01   95% hv: 0.167440, 0.174200
AlternatingZDT6        prob_bin: 0.50   95% hv: 0.140555, 0.147728
AlternatingZDT6        prob_bin: 0.01   95% hv: 0.164799, 0.171331

[lukepmccombs]

I've looked through various implementations and papers, and I think the observed behavior was just an unintentional aspect added when parameterizing prob_bin.

Firstly, I'll point out that when implementing the sampling for bounded simulated binary crossover, it is more convenient to work with the two parents ordered by the higher and lower value.

When randomly ordering any two values, if you assign them equal weight of being the "first" (prob_bin = 0.5 as in all other implementations I found, including early pymoo versions), the resulting distribution is going to be the same no matter the original ordering. Once prob_bin != 0.5, however, the assignment of the weights relative to the ordering starts to matter.

My case is that the weights should be assigned by the original ordering of the parents, which this PR enforces. The current implementation for pymoo assigns the weights according to the current ordering at the time of choosing, which is their by-value ordering that was chosen for convenience when sampling. For a single variable, this doesn't matter much since it just reorders the children, but with multiple variables you get the extremal parameter bias I had demonstrated.

[blankjul]

Hi @lukepmccombs,

I have finally had a chance to think it through and you've identified a real problem with the SBX prob_bin parameter semantics.

I've created an alternative solution in PR #725 that addresses the same core issue but with a slightly different approach. Instead of modifying the swapping logic extensively, I preserve parent identity while keeping the SBX calculations intact.

My implementation ensures that:

• prob_bin=0.0: Child 1 always inherits from Parent 1, Child 2 from Parent 2 (no exchange)
• prob_bin=0.25: 25% probability that children exchange parent values
• prob_bin=0.5: 50% probability (equivalent to current behavior but semantically correct)
• prob_bin=1.0: Children always inherit from opposite parents

Could you take a look at my approach and let me know what you think? Does this address the same concerns you had with the original implementation? I'm curious to get your feedback on whether this solution would work for your use case.

The key difference is that my solution focuses on making prob_bin control the probability of parent value exchange rather than just removing bias, which I think aligns with the intuitive expectation of what that parameter should do.

Thanks for bringing this issue to attention!

[lukepmccombs]

Resolved with an alternate implementation in #725