Describe the issue:

numpy.unwrap produces incorrect or misleading results when given unsigned integer arrays as input—especially when the sequence contains decreasing values.

This seems to be caused by the intermediate subtraction (e.g., np.diff) failing to properly interpret negative differences in unsigned data types, leading to large positive wrap-around values, which are then incorrectly unwrapped.

The function should either:

• Internally cast inputs to float64 before computing differences (if not already), or

• Explicitly reject uint* input types with a helpful error message or warning.

Since unwrap is typically used on floating-point phase data, using unsigned integers is not common, but the behavior should still be well-defined or guarded.

Reproduce the code example:

import numpy as np

x1 = array([5, 1], dtype=uint64)
t = numpy.unwrap(x1)
print(t) # out is [ 5.00000000e+00 -1.84467441e+19] - as unexpected

x2 = array([5, 1], dtype=int64)
t = numpy.unwrap(x2)
print(t) # out is [5.         7.28318531] - as expected

Error message:

None

Python and NumPy Versions:

2.3.1
3.12.0 | packaged by Anaconda, Inc. | (main, Oct 2 2023, 17:29:18) [GCC 11.2.0]

Runtime Environment:

[{'numpy_version': '2.3.1',
'python': '3.12.0 | packaged by Anaconda, Inc. | (main, Oct 2 2023, '
'17:29:18) [GCC 11.2.0]',
'uname': uname_result(system='Linux', node='gpu-node5', release='5.4.0-100-generic', version='#113-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022', machine='x86_64')},
{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
'found': ['SSSE3',
'SSE41',
'POPCNT',
'SSE42',
'AVX',
'F16C',
'FMA3',
'AVX2',
'AVX512F',
'AVX512CD',
'AVX512_SKX',
'AVX512_CLX',
'AVX512_CNL',
'AVX512_ICL'],
'not_found': ['AVX512_KNL', 'AVX512_KNM', 'AVX512_SPR']}},
{'architecture': 'SkylakeX',
'filepath': '/home/miniconda3/envs/pbt/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-56d6093b.so',
'internal_api': 'openblas',
'num_threads': 64,
'prefix': 'libscipy_openblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.29'}]

Context for the issue:

I'd like to acknowledge that this may not be a bug. Similar to how integer arrays are not automatically cast to float in other numerical operations, it's reasonable that numpy.unwrap also does not perform implicit type conversion.
The behavior, while surprising, is consistent with NumPy's general approach of preserving input types and avoiding silent casting.

If my understanding is incorrect or if this is intended behavior, I sincerely apologize for the noise.