Fix dtype casting issue with numpy in LlamaTune adapter

[kkanellis]

Pull Request

Description

This PR addresses a breaking change in NumPy's universal function (ufunc) behavior in version 2.0, specifically affecting np.clip in the LlamaTune adapter code.

Key Changes:

• Resolves an issue where configuration retrieval fails due to type casting differences
• Explicitly casts np.clip output from NumPy data type (e.g., int64) to native Python type (e.g., int)

Problem Context:
In NumPy 2.0+, when ufuncs receive Python scalars as input, the output is no longer automatically cast to Python scalars. This prevents retrieving previously suggested configurations stored in self._suggested_configs dict during self.inverse_transform method calls.

Technical Solution:
Implement explicit type casting to ensure consistent configuration representation in self._suggested_configs across self.transform and self.inverse_transform method calls.

• Closes LlamaTune incompatible with numpy>=2.0 #935

---

Type of Change

• 🛠️ Bug fix

---

Testing

• Environment: Ubuntu 22.04 with Python 3.13
• NumPy Versions Tested: 1.26.4 and 2.2.2
• Verification: Existing test suite passed across both versions

---

[bpkroth]

Thanks for digging into this. Adjusting slightly to also remove the numpy version pinning.

[bpkroth]

Made a few small tweaks, but LGTM. Thanks for tracking this down!

[bpkroth]

Actually, it looks like this is still failing a test:

pytest -n0 mlos_bench/mlos_bench/tests/optimizers/toy_optimization_loop_test.py -k smac

...

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/opt/conda/envs/mlos/lib/python3.13/site-packages/smac/main/smbo.py", line 431, in save
    self._runhistory.save(path / "runhistory.json")
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/mlos/lib/python3.13/site-packages/smac/runhistory/runhistory.py", line 805, in save
    assert self._running == len(self._running_trials)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

That doesn't happen with numpy<2.0, but with numpy 2.2.2 it does happen whether I use the version check or the try/except.

@kkanellis can you please take another look?

Thanks!

New bug found with smac3

[bpkroth]

@kkanellis were you able to track the source of this down at all?
From my quick glance, you're right that smac3 updated to v2.3.0 and started allowing numpy 2.0 (prior apparently both we and smac3 were disallowing it).
However, now there's a different bug with smac3.
Would be good to at least track that down and submit an Issue upstream to them.

[kkanellis]

I will try to track this down tomorrow.

In any case, since this look like a different bug/issue with SMAC, I propose merging this (w/o the change on the numpy version), and open a new issue just for this.

[bpkroth]

As discussed, merging as is since we are fairly confident this fixes one issue.
Will lift the numpy 2.0 restriction later once the SMAC issue is tracked down.