Description of the bug
Checked against the latest PyPI release (July 2026 audit). As part of a benchmarking-fidelity audit we evaluated identical inputs through three implementations of CEC2022: (a) the organizers' C code and (b) the organizers' own Python port (both from https://github.com/P-N-Suganthan/2022-SO-BO, mutually agreeing to 1e-12), and (c) opfunu's cec_based.cec2022.F*2022 classes — all with the same official input_data shift/rotation files, at D = 10 and D = 20.
Result: opfunu agrees with the official values only on F22022. The other 11 of 12 functions return systematically different values at identical inputs (far above floating-point tolerance; at 1,000 seeded uniform points per function the median |Δf| ranges from ~2·10² on F3/F4 up to ~2·10¹⁸ on F8). Shift data is read identically — at the official optimum both return exactly F* — so the divergence is in the function compositions themselves.
Root cause proven for F1 (Zakharov base): opfunu.utils.operator.zakharov_func computes the second term without the index weights:
python
temp = np.sum(0.5 * x) # actual
official: temp = np.sum(0.5 * np.arange(1, D+1) * x)
Steps To Reproduce
-
Self-contained check of the root cause (no C code needed):
python
from opfunu.utils.operator import zakharov_func
x = [1.0, 2.0, 3.0]
print(zakharov_func(x)) # 104.0
s2 = sum(vv for v in x)
t = 0.5(11.0 + 22.0 + 3*3.0) # official index weights
print(s2 + t2 + t4) # 2464.0
-
Full-suite check: clone https://github.com/P-N-Suganthan/2022-SO-BO, use the official Python port (CEC2022.py, column-vector input x.reshape(D, 1)), and compare F12022(ndim=10).evaluate(x) against the official cec22_test_func(x, f=1) at any non-optimum point — the values differ by orders of magnitude, while F2 matches to ~1e-12.
-
Sanity check that excludes a harness error: evaluate both at the official shift vector o from input_data — both return exactly 300.0 for F1 (the shift files are read identically).
Additional Information
Impact: absolute error values, success rates, and fixed-target statistics computed through opfunu's CEC2022 do not reproduce against the official suite. In our 21-algorithm study the rank-level comparisons happened to be robust (Spearman rho = 0.974 at 10D and 0.986 at 20D between the two implementations' leaderboards), but value-level results are not comparable. Suggested fix: restore the index weights in the Zakharov component of F1, then diff each remaining function against the official C code at random points — we can share our triangulation harness (a ~50-line ctypes bridge) and the per-function divergence table with reproduction seeds. Findings from a systematic implementation-fidelity audit; a preprint with full methodology is available on request. Happy to open a PR for the F1 fix.
Description of the bug
Checked against the latest PyPI release (July 2026 audit). As part of a benchmarking-fidelity audit we evaluated identical inputs through three implementations of CEC2022: (a) the organizers' C code and (b) the organizers' own Python port (both from https://github.com/P-N-Suganthan/2022-SO-BO, mutually agreeing to 1e-12), and (c) opfunu's cec_based.cec2022.F*2022 classes — all with the same official input_data shift/rotation files, at D = 10 and D = 20.
Result: opfunu agrees with the official values only on F22022. The other 11 of 12 functions return systematically different values at identical inputs (far above floating-point tolerance; at 1,000 seeded uniform points per function the median |Δf| ranges from ~2·10² on F3/F4 up to ~2·10¹⁸ on F8). Shift data is read identically — at the official optimum both return exactly F* — so the divergence is in the function compositions themselves.
Root cause proven for F1 (Zakharov base): opfunu.utils.operator.zakharov_func computes the second term without the index weights:
python
temp = np.sum(0.5 * x) # actual
official: temp = np.sum(0.5 * np.arange(1, D+1) * x)
Steps To Reproduce
Self-contained check of the root cause (no C code needed):
python
from opfunu.utils.operator import zakharov_func
x = [1.0, 2.0, 3.0]
print(zakharov_func(x)) # 104.0
s2 = sum(vv for v in x)
t = 0.5(11.0 + 22.0 + 3*3.0) # official index weights
print(s2 + t2 + t4) # 2464.0
Full-suite check: clone https://github.com/P-N-Suganthan/2022-SO-BO, use the official Python port (CEC2022.py, column-vector input x.reshape(D, 1)), and compare F12022(ndim=10).evaluate(x) against the official cec22_test_func(x, f=1) at any non-optimum point — the values differ by orders of magnitude, while F2 matches to ~1e-12.
Sanity check that excludes a harness error: evaluate both at the official shift vector o from input_data — both return exactly 300.0 for F1 (the shift files are read identically).
Additional Information
Impact: absolute error values, success rates, and fixed-target statistics computed through opfunu's CEC2022 do not reproduce against the official suite. In our 21-algorithm study the rank-level comparisons happened to be robust (Spearman rho = 0.974 at 10D and 0.986 at 20D between the two implementations' leaderboards), but value-level results are not comparable. Suggested fix: restore the index weights in the Zakharov component of F1, then diff each remaining function against the official C code at random points — we can share our triangulation harness (a ~50-line ctypes bridge) and the per-function divergence table with reproduction seeds. Findings from a systematic implementation-fidelity audit; a preprint with full methodology is available on request. Happy to open a PR for the F1 fix.