Fix runtime test failures with NumPy 2.0 / Windows

[pareshjoshij]

I ran the tests locally on Windows with NumPy 2.0 and noticed test_ctype_assumptions.py was failing.

I thought the issue was that np.long has been removed in the new version, and that types like intc and longdouble are no longer strict aliases (causing is checks to fail). I tried to solve this by removing those specific failing cases so the rest of the suite can pass.

I hope this is the right approach—please let me know if there is a better way to handle these types!

Thanks!

[jorenham]

NumType currently only supports the latest NumPy (2.3 at the moment). Is this also an issue in that case?

[jorenham]

Could you also post the output of your np.show_runtime()? Because it's a bit strange that this issue did not show up in the Windows CI runner.

[pareshjoshij]

Could you also post the output of your np.show_runtime()? Because it's a bit strange that this issue did not show up in the Windows CI runner.

Apologies for the confusion @jorenham sir , I am actually running NumPy 2.3.5 locally. np.show_runtime() appears to be a typo for np.show_config()—would you like me to post the output of that instead?

[jorenham]

numpy.show_runtime() wasn't a typo :)

[jorenham]

I am actually running NumPy 2.3.5 locally

Then it'd help if you could update the PR title, description, and commit messages accordingly (squashing commits is fine afaik).

[pareshjoshij]

numpy.show_runtime() wasn't a typo :)

Thank you for clarifying! I've installed the necessary dependency and successfully captured the output of np.show_runtime().

This confirms my environment is Windows (AMD64) running NumPy 2.3.5.

Output of np.show_runtime():

[{'numpy_version': '2.3.5',
  'python': '3.13.5 (tags/v3.13.5:6cb20a2, Jun 11 2025, 16:15:46) [MSC v.1943 64 bit (AMD64)]',
  'uname': uname_result(system='Windows', node='DESCKTOP-9909', release='10', version='10.0.19044', machine='AMD64')},
 {'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
                      'found': ['SSSE3', 'SSE41', 'POPCNT', 'SSE42', 'AVX', 'F16C', 'FMA3', 'AVX2'],
                      'not_found': ['AVX512F', 'AVX512CD', 'AVX512_SKX', 'AVX512_CLX', 'AVX512_CNL', 'AVX512_ICL']}},
 {'ignore_floating_point_errors_in_matmul': False},
 {'architecture': 'Haswell',
  'filepath': 'D:\\download c\\New folder\\OneDrive\\Desktop\\dev\\numtype\\venv\\Lib\\site-packages\\numpy.libs\\libscipy_openblas64_-9e3e5a4229c1ca39f10dc82bba9e2b2b.dll',
  'internal_api': 'openblas',
  'num_threads': 4,
  'prefix': 'libscipy_openblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.30'}]

[jorenham]

Ah it must because you have an AMD64 machine then. Too bad that there isn't a github runner image for that.

[jorenham]

But then this begs the question: What are np.intc, np.long, and np.longdouble aliases to, on your machine?
Because this shows that the assumptions that these assertions verify are clearly incorrect. We should therefore adjust the underlying assumptions, rather than remove the assertions.

[pareshjoshij]

But then this begs the question: What are np.intc, np.long, and np.longdouble aliases to, on your machine? Because this shows that the assumptions that these assertions verify are clearly incorrect. We should therefore adjust the underlying assumptions, rather than remove the assertions.

@jorenham sir I removed np.long because the migration guide listed it as removed.

However, checking locally on Windows (NumPy 2.3.5) shows it actually still exists here. Here is the output

np.intc is: int32
np.long is: int32
np.longdouble is: float64
Is longdouble == float64? True
It seems Windows behaves differently than the docs suggest. Should I restore the check and update the assertions for these aliases?

[pareshjoshij]

But then this begs the question: What are np.intc, np.long, and np.longdouble aliases to, on your machine? Because this shows that the assumptions that these assertions verify are clearly incorrect. We should therefore adjust the underlying assumptions, rather than remove the assertions.

@jorenham sir I removed np.long because the migration guide listed it as removed.

However, checking locally on Windows (NumPy 2.3.5) shows it actually still exists here. Here is the output

np.intc is: int32 np.long is: int32 np.longdouble is: float64 Is longdouble == float64? True It seems Windows behaves differently than the docs suggest. Should I restore the check and update the assertions for these aliases?

I conflated np.long with np.longfloat :(

[pareshjoshij]

@jorenham Sorry for the noise! I've moved this to Draft.

Quick check: is this longdouble validation approach the right direction? I'll fix the CI/style errors once I know the logic is acceptable. Thanks!

[jorenham]

Quick check: is this longdouble validation approach the right direction? I'll fix the CI/style errors once I know the logic is acceptable. Thanks!

It's not really testing any assumptions this way. The re-adjusted assumption we should test is that on windows longdouble is either float64 or float96, and on linux it's always float128.