Skip to content

TST: mask DeprecationWarning in xfailed test #15610

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

Merged
merged 1 commit into from
Feb 23, 2020

Conversation

mattip
Copy link
Member

@mattip mattip commented Feb 19, 2020

xfailed tests are still run, they are expect to raise. This one was also emitting a DeprecationWarning, which is confusing

@mattip
Copy link
Member Author

mattip commented Feb 19, 2020

@r-devulap this is failing with reciprocal. After a deep dive, I found that the problem is that for certain values of the jj stride, especially -1, the IS_OUTPUT_BLOCKABLE_UNARY macro fails, we revert to glibc's implementation, and sometimes (especially for reciprocal) it is an ULP or two off. Can you mock the IS_OUTPUT_BLOCKABLE_UNARY macro and skip the assert_equal if it will fail?

@seberg
Copy link
Member

seberg commented Feb 19, 2020

@mattip what deprecation warning is this giving? I do not quite understand. Clip used to include a deprecation warning, which should never be hit. But that is now even moved the dtype creation phase, so what is going on?

@r-devulap
Copy link
Member

r-devulap commented Feb 20, 2020

hmm this is little bizarre. I can't reproduce this error locally on the manylinux2010 docker despite running 10,000 times and it doesn't seem like it fails on the CI consistently too. Reciprocal function is just a divide and should produce exactly the same result no matter what SIMD variant it uses (including the scalar code). There should be no ULP error.

@mattip
Copy link
Member Author

mattip commented Feb 20, 2020

@r-devulap the process to run the test builds a wheel with a manylinux2010 docker and tests with the matthewbrett/trusty:32 docker. If you run with a debugger (which I couldn't successfully do) or add a print when the IS_OUTPUT_BLOCKABLE_UNARY macro fails (which is what I ended up doing) you will see the macro does not succeed for all strides. Any failure of that macro means that part of the test is not checking what you want it to check, and so should be considered a failure.

If you want to reproduce the exact process the build follows, you can use bash buildscript.sh where buildscript.sh is below, but I think your time would be better spent thinking when the macro would fail, and avoid those cases.

``` # Once off, modify the numpy-wheel repo # Add the following to `config.sh` to use the current state of # the numpy submodule, otherwise it uses the git commit in # `build_commit` function clean_code { echo skipping git update } # Make the following changes to multibuild diff --git a/docker_test_wrap.sh b/docker_test_wrap.sh index a37b7e0..7305252 100755 --- a/docker_test_wrap.sh +++ b/docker_test_wrap.sh @@ -1,6 +1,7 @@ #!/bin/bash # Install and test steps on Linux -set -e +set -ex +export PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

Get needed utilities

MULTIBUILD_DIR=$(dirname "${BASH_SOURCE[0]}")
diff --git a/travis_linux_steps.sh b/travis_linux_steps.sh
index 0fc6a98..863e23a 100644
--- a/travis_linux_steps.sh
+++ b/travis_linux_steps.sh
@@ -11,7 +11,6 @@

install_run

set -e

-MANYLINUX_URL=${MANYLINUX_URL:-https://5cf40426d9f06eb7461d-6fe47d9331aba7cd62fc36c7196769e4.ssl.cf2.rackcdn.com}

Default Manylinux version

Warning: ignored if DOCKER_IMAGE variable is set.

@@ -19,7 +18,7 @@ MANYLINUX_URL=${MANYLINUX_URL:-https://5cf40426d9f06eb7461d-6fe47d9331aba7cd62fc
MB_ML_VER=${MB_ML_VER:-1}

Get our own location on this filesystem

-MULTIBUILD_DIR=$(dirname "${BASH_SOURCE[0]}")
+MULTIBUILD_DIR=multibuild

Allow travis Python version as proxy for multibuild Python version

MB_PYTHON_VERSION=${MB_PYTHON_VERSION:-$TRAVIS_PYTHON_VERSION}


This is the content of `buildscript.sh`

cd numpy-wheel
#remove previous run's wheel
sudo rm -rf wheelhouse/*
export repo_dir=numpy
export build_commit=e94cec800304a6a467cf90ce4e7d3e207770b4b4
export build_depends=cython
export test_depends="pytest hypothesis"
export plat=x86_64
export unicode_width=32
export wheelhouse_uploader_username=travis-worker
export daily_commit=master
export extra_argv="'--disable-pytest-warnings'"
export mb_python_version=3.7
export mb_ml_ver=2010
export plat=i686
export env_vars_path=env_vars_32.sh

set -x
source multibuild/common_utils.sh
source multibuild/travis_steps.sh

this uses a manylinux2010 docker to build the wheel

build_wheel $repo_dir $plat
sudo rm -rf tmp_for_test

This uses the other docker to install and test the wheel

install_run $plat

@mattip
Copy link
Member Author

mattip commented Feb 20, 2020

@seberg I convinced myself by adding a xxxx = xxxx failure line (or import pdb; pdb.set_trace()) in the code where the python code emits the warning and run this test only python runtest -- -k test_clip_scalar_nan_propagation. For me it hit hit the warning.

@r-devulap
Copy link
Member

@mattip I am not sure what is causing this failure, but the ULP error seems very small (< 1 ULP, max relative error of 1.1176388e-16). May be using assert_array_max_ulp instead of assert_equal might be more suitable? Submitted a PR with this change #15615. Do you think that might suffice?

@seberg
Copy link
Member

seberg commented Feb 20, 2020

Sorry matti, nvm. I was confused, because I checked a non-development version and thought there was no datetime/timedelta loop for np.isnan. But we have one now, so this makes perfect sense.

@mattip
Copy link
Member Author

mattip commented Feb 20, 2020

Please wait until gh-15615 is settled before merging this, the CI failure here is interesting and difficult to reproduce, and I think merging it will make the log dissapear.

@@ -2018,7 +2018,8 @@ def test_NaT_propagation(self, arr, amin, amax):
# NOTE: the expected function spec doesn't
# propagate NaT, but clip() now does
expected = np.minimum(np.maximum(arr, amin), amax)
actual = np.clip(arr, amin, amax)
with assert_warns(DeprecationWarning):
actual = np.clip(arr, amin, amax)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about @pytest.mark.filterwarnings("ignore::DeprecationWarning")? Using assert_warns seems out of place for something that will be changed in the future, tests for warnings belong in test_deprecations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Another option is to delete this test: I think it started out as an edge case reported by hypothesis, and has now both an xfail and a warning filter.

@charris charris merged commit 124dc4e into numpy:master Feb 23, 2020
@charris
Copy link
Member

charris commented Feb 23, 2020

Thanks Matti.

@mattip mattip deleted the xfail-warning branch November 2, 2020 08:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants