TL;DR: NumPy 2 removed the implicit conversion that used to turn floats into ints for you. Find where a float (often a numpy.float64 from a computation) reaches an integer-only argument like an index or a shape, and wrap it in int() or convert with astype. The behavior change is deliberate, so casting at the boundary is the fix, not a workaround.

## The error

```text
"TypeError: 'numpy.float64' object cannot be interpreted as an integer" after numpy 2 upgrade
```

## Steps to fix

1. Reproduce and locate: run the failing snippet and read the traceback to the exact line and argument.
   Expected: You see which call receives the float64, for example arr[int_like_float] or np.zeros(some_float).

2. Check where the float comes from: print its type; it is usually numpy.float64 produced by division or a ufunc.
   Expected: You confirm the value is a genuine float, not a corrupted int.

3. Cast explicitly at the boundary: wrap the argument in int(), or convert arrays with .astype(np.int64) before use.
   Expected: The snippet runs without the TypeError.

4. Search the codebase for the same pattern: look for indexing, range(), reshape, and shape arguments fed by computed floats.
   Expected: You find and fix the remaining sites before they fail in production.

5. Run the test suite on NumPy 2.
   Expected: All numeric tests pass with explicit casts in place.

## Use this when

- Code raises 'numpy.float64' object cannot be interpreted as an integer after a NumPy 2 upgrade
- An agent bumped numpy and downstream numeric code broke on indexing or shapes
- You are migrating a codebase from NumPy 1.x to 2.x and need the mechanical fix pattern

## Not for this skill when

- NumPy 2 string or dtype promotion errors, which are separate NEP 50 changes
- NaN or inf handling differences, which need value-level fixes
- C-extension compilation failures against NumPy 2 headers

## Variant phrasings

- numpy 2 integer conversion error
- TypeError float object cannot be interpreted as an integer numpy
- NEP 50 migration implicit conversion removed

## Why it happens

NEP 50 reworked NumPy's type promotion, and one deliberate casualty was the silent conversion of Python and NumPy floats to integers in integer-only positions. NumPy 1.x would quietly truncate; NumPy 2 raises instead, because silent truncation hid bugs. The fix belongs at the boundary where the float meets the integer slot, which also documents the intended rounding.

## Edge cases

- int() truncates toward zero; if the old code relied on that, keep int(), but if it needs rounding, use round() or np.rint first.
- Division now yields float64 where it may once have yielded ints in old code paths; audit divisions feeding shapes.
- Third-party libraries pinned to NumPy 1.x behavior may need upgrading alongside, or they will raise the same error internally.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bDRtjuYZegaqHmQl7BmZMw