dual_annealing prints overflow warning

[MyNameIsTrez]

The below minimal reproducible example prints the warning RuntimeWarning: overflow encountered in scalar multiply:

Using: x86_64
block_size_x=3, time=0.000
block_size_x=1, time=0.000
/workspaces/dev-container/rocm-libraries/projects/rocprim/tuning/.venv/lib/python3.10/site-packages/scipy/optimize/_dual_annealing.py:267: RuntimeWarning: overflow encountered in scalar multiply
  pqv_temp = 1.0 - ((1.0 - self.acceptance_param) *
best performing configuration:
block_size_x=3, time=0.000

The warning is printed at scipy/optimize/_dual_annealing.py:267, but it is caused by kernel_tuner/strategies/common.py passing sys.float_info.max to scipy here.

I don't know whether this warning may cause less optimal configs to be chosen, but it would be nice to have it fixed regardless.

I am using Kernel Tuner version 1.3.1 from pypi (latest version), which is from Jan 21, 2026.

I work for AMD, and we are running into this warning in rocPRIM its autotuning code here. It uses the dual_annealing strategy.

Setup

python3 -m venv .venv && \
source .venv/bin/activate && \
python3 -m pip install kernel-tuner numpy

Run

import kernel_tuner
import numpy as np

np.random.seed(42)

kernel_tuner.tune_kernel(
    kernel_name="foo",
    kernel_source="void foo(int) { }",
    problem_size=1,
    arguments=[np.int32(0)],
    tune_params={"block_size_x": range(1, 8)},
    strategy="dual_annealing",
    restrictions="block_size_x < 4",
)

Latest

I confirmed that this issue isn't fixed in the latest version of the master branch, even though common.py got a seemingly related change between version 1.3.1 and the master branch when comparing them:

--- .venv/lib/python3.10/site-packages/kernel_tuner/strategies/common.py        2026-03-06 17:02:41.869348387 +0000
+++ latest_common.py    2026-03-06 17:04:39.090859965 +0000
@@ -73,6 +73,7 @@
         snap=True,
         return_invalid=False,
         return_raw=None,
+        invalid_value=sys.float_info.max,
     ):
         """An abstract method to handle evaluation of configurations.
 
@@ -100,6 +101,7 @@
             self.return_raw = f"{tuning_options['objective']}s"
         self.results = []
         self.budget_spent_fraction = 0.0
+        self.invalid_return_value = invalid_value
 
 
     def __call__(self, x, check_restrictions=True):
@@ -168,7 +170,7 @@
         else:
             # this is not a valid configuration, replace with float max if needed
             if not self.return_invalid:
-                return_value = sys.float_info.max
+                return_value = self.invalid_return_value
 
         # include raw data in return if requested
         if self.return_raw is not None:

1. I clone the Kernel Tuner repository:

git clone https://github.com/KernelTuner/kernel_tuner && \
cd kernel_tuner

2. I install poetry:

curl -sSL https://install.python-poetry.org | python3 - && \
poetry --version && \
poetry self add poetry-plugin-export

3. I set up a virtual environment:

python3 -m venv .venv && \
source .venv/bin/activate && \
python3 -m pip install numpy && \
poetry install --with test,docs -E hip

4. I run pip show kernel_tuner to verify that it successfully installed the cloned Kernel Tuner repository.
5. I run python3 main.py, which still prints the same warning.

I am able to "fix" the warning by changing invalid_value=sys.float_info.max to invalid_value=np.inf in CostFunc its constructor, but I don't know whether this is the proper fix, or whether this might break something else.

There are other places in the codebase where sys.float_info.max is used, so I think those should be individually checked to see if they should be replaced with np.inf.

[benvanwerkhoven]

Thank you for reporting this issue and your detailed analysis!

Dual annealing is one of the few strategies (together with simulated annealing) that directly uses the value returned by the cost function to compute an acceptance probability for accepting the new location. Most other strategies only sort these values, but do not directly use the value itself in any computations. This is why the annealing methods can suffer from numerical overflows or division by zero.

Your suggestion for fixing the warning on dual annealing is valid. I have checked the scipy code for dual annealing and the infinite value should make sure that the new location is never accepted, which is what we want in case of an invalid config.

The related change on master that you mentioned makes it possible to specify the invalid value returned by the cost function per strategy, which makes it easy to use np.inf for dual annealing and sys.float_info.max for the other strategies.

I have also inspected the other uses of sys.float_info.max in the code base, but these are only used when sorting values for which its use is acceptable.

I'm opening a pull request that fixes the warning.