TypeError in PolynomialMutation and SBXCrossover

[franzscheuer]

I came across a small bug in the implementation of PolynomialMutation and SBXCrossover.

Both use pow(...) multiple times. Sometimes the exponent is between 0 and 1 by default. Therefore, complex numbers are introduced if the base is negative and a TypeError occurs.

My solution proposal is to add abs(...) around the base of the deltaq computation in PolynomialMutation (line 74 and 78) and around the base of the betaq computation in SBXCrossover (line 173, 175, 182 and 184).

[franzscheuer]

Note: I just noticed the line numbers are off by a few lines in the original post.

[ajnebro]

Hi.
I have never found such situations when using polynomial mutation and SBX crossover. What distribution index values are you using?

Antonio

[franzscheuer]

Hi,

for example let's look at the following code-snipet:

betaq = pow(rand*alpha, (1.0/(self.distribution_index + 1.0)))

For any distribution_index -2 > x > 0 there is no problem, since the exponent will not be a fraction value between -1 and 1.

But anything else will result in a value between -1 and 1. And any value to the power of such a value, will be interpreted as root. And the root of a negative number is a complex number.

[ajnebro]

I have used distribution index values within the range (5.0, 400.0).

[ajnebro]

I've applied those operators in many studies in the last 15 years and I have never had an error related to complex numbers in pow(), so this issue is intrigues me.

[franzscheuer]

I see your point. But mathematically it makes sense (in my opinion) to add abs(). I don't always get a negative base, but sometimes.

[ajnebro]

The issue is to decide that, if you get a negative base, that should be considered as an error or as a valid value. If it is the former, using abs() would hide the error, which could be very difficult to find later if an algorithms yields unexpected results.

[franzscheuer]

Sorry for the late answer, I totally get your concern. But since my input variables are not strange at all in my opinion, they somehow still trigger that behavior. I use 9 variables, with lower boundaries [-5.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] and upper boundaries [0.0, 50.0, 50.0, 500.0, 1000.0, 2.5, 200.0, 2.5, 50.0]. I don't see how those variables can produce complex numbers.