Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter upstream warning raised by np.finfo(np.longdouble) on WSL1 #1310

Conversation

joshuacwnewton
Copy link
Contributor

@joshuacwnewton joshuacwnewton commented Mar 23, 2024

Description

This PR filters an upstream warning regarding broken support for np.longdouble, raised by np.finfo(np.longdouble) when numpy>=1.25 is used on WSL1.

UserWarning: Signature b'\x00\xd0\xcc\xcc\xcc\xcc\xcc\xcc\xfb\xbf\x00\x00\x00\x00\x00\x00' for
<class 'numpy.longdouble'> does not match any known type: falling back to type probe function.
This warnings indicates broken support for the dtype!
 machar = _get_machar(dtype)

NB: The context in which type_info is called on np.longdouble is here:

nibabel/nibabel/casting.py

Lines 664 to 670 in 0e925ab

def best_float():
"""Floating point type with best precision
This is nearly always np.longdouble, except on Windows, where np.longdouble
is Intel80 storage, but with float64 precision for calculations. In that
case we return float64 on the basis it's the fastest and smallest at the
highest precision.

long_info = type_info(np.longdouble)

Given that nibabel already tries to avoid np.longdouble on Windows, I think it should be fine to filter this warning?

Notes:

Related issues/PRs

Fixes #1309.

This commit filters the following warning:

> UserWarning: Signature b'\x00\xd0\xcc\xcc\xcc\xcc\xcc\xcc\xfb\xbf\x00\x00\x00\x00\x00\x00' for
> <class 'numpy.longdouble'> does not match any known type: falling back to type probe function.
> This warnings [sic] indicates broken support for the dtype!
>  machar = _get_machar(dtype)

 To ensure that this warning is only filtered on WSL1, we try to detect WSL
 by checking for a WSL-specific string from the uname, which appears to be
 endorsed by WSL devs.
 (microsoft/WSL#4555 (comment))

 I also tried checking the `WSL_INTEROP` and `WSL_DISTRO_NAME` environment
 variables as suggested in the above linked issues, but I preferred reusing
 the `platform` module that was already imported inside `casting.py`.

 There is perhaps a more thorough approach where we collect all raised warnings,
 test the collected warnings, etc. but I didn't want to overcomplicate things.
@effigies
Copy link
Member

Thanks for this! Yeah, I think detecting the platform is overkill and would suggest just ignoring unconditionally.

@effigies
Copy link
Member

LGTM. Please feel free to add your name, affiliation and ORCID to https://github.com/nipy/nibabel/blob/master/.zenodo.json in order to be credited as an author on future releases.

Copy link

codecov bot commented Mar 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.27%. Comparing base (0e925ab) to head (50dd737).

❗ Current head 50dd737 differs from pull request most recent head 2978ee8. Consider uploading reports for the commit 2978ee8 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1310   +/-   ##
=======================================
  Coverage   92.27%   92.27%           
=======================================
  Files          99       99           
  Lines       12460    12462    +2     
  Branches     2561     2562    +1     
=======================================
+ Hits        11497    11499    +2     
  Misses        641      641           
  Partials      322      322           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@effigies effigies added this to the 6.0 milestone Mar 23, 2024
@joshuacwnewton
Copy link
Contributor Author

LGTM. Please feel free to add your name, affiliation and ORCID to https://github.com/nipy/nibabel/blob/master/.zenodo.json in order to be credited as an author on future releases.

My apologies for not understanding, but should I edit this file in the context of this PR? Or, separately?

(Looking at the history of this file, many of the edits appear to be authored by yourself, hence my confusion.)

    {
      "affiliation": "Polytechnique Montréal, Montréal, CA",
      "name": "Newton, Joshua",
      "orcid": "0009-0005-6963-3812"
    },

@effigies
Copy link
Member

I'm listed as the author because we have a script to reorder them (and I do also add them sometimes).

Please go ahead and add it yourself in this PR.

@effigies effigies merged commit 714d757 into nipy:master Mar 23, 2024
@joshuacwnewton joshuacwnewton deleted the jn/1309-filter-numpy-warning-longdouble-wsl branch March 24, 2024 01:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Noisy UserWarning is thrown (np.longdouble) when importing nibabel with numpy>=1.25 on WSL1
2 participants