Bugfix cec2022 benchmarks

[firestrand]

Closes #

📑 Description

This change corrects the cec2022 benchmark as compared with published cec2022 source.

✅ Checks

• My pull request adheres to the code style of this project
• My code requires changes to the documentation
• I have updated the documentation as required
• All the tests have passed

ℹ Additional Information

[thieu1995]

@firestrand,

Could you please add a 'shifted' parameter to this type of function? Kindly avoid fixed the shifted value within the function. This will make the function more reusable.

[thieu1995]

@firestrand ,

This function too, you can add parameter for it.

[firestrand]

Please confirm you want parameterized after reading.
I specifically didn't go with a parameterized because I was thinking it would require either an if condition to check the parameter and shift or not, or always perform the shift just with a 0 for some cases if no shift is desired. While small this could introduce some extra processing. So having a shifted override function which calls the base unshifted seemed like the best performance vs clean approach.

That said if you feel going with a parameterized approach matches the codebase better I can go that direction, and if so prefer passing the shift value as 1, -1 etc. with a default of 0 instead of an if check.

Thoughts?

[thieu1995]

@firestrand,

Yes, please set up the parameter name that match with function name. Also set up the default value for it. You don't need to check if else condition here. Your function will be reused more in future.
Other sections looking good. I will accept this PR after you do it. Thanks

[firestrand]

@thieu1995
Started to make the change and it doesn't seem right for the codebase.
Changing the signature to something like def happy_cat_func(x, shift=0.0) works fine for when the benchmark is either calling the shifted or unshifted directly. ie. happy_cat_func(x, shift=-1.0) or happy_cat_func(x). However with the composite benchmarks the code does something like self.g2 = operator.happy_cat_func then in the evaluate we will get self.g2(mz[self.n1:self.n2], shift=-1.0) which will be different from the other self.g1,g3 calls.

I considered a functional approach, which would be something like def happy_cat_func(shift=0.0): def inner(x): <existing logic> which would then transform the self.g2 = operator.happy_cat_func(-1.0) and the evaluate code would be the same. But then the functions that currently call the function directly would look like operator.happy_cat_func()(x) which would be different.

The last alternative is leaving things the way I have with a separate function definition for the shifted case so the signatures in the benchmark stay the same.

So advise option 1, 2, or 3 given this information.

[thieu1995]

@firestrand ,

I forgot to tell you when I defined self.g1 =..., self.g2=... in the init function. It is just for short code.
Now because you have parameter in the function, then you don't have to define g1, g2,... function.

Just write full function in evaluate().
For example, return operator.happy_cat_func((mz[self.n1:self.n2], shift=1.0) + operator.katsuura_func(mz[self.n1:self.n2], shift=-1.0,...) like that.

[firestrand]

Found a reference for levy function, looks like the original is correct but that the expectation for the cec function was a 0 optimal shifted version. So went with a shift parameter like the hgbat and happy_cat with a default.

[thieu1995]

@firestrand ,

Thank you, If you have time, please take a look at other CEC set such as CEC2017 and CEC2014.