Fix UniformGrid.x docstring

[MatthewFlamm]

Overview

When implementing #2510, this bug was found. I'm not sure how this could pass the current doctest since it compares the strings 🤷

[adeak]

Good catch.

I'm not sure how this could pass the current doctest since it compares the strings 🤷

That's reaaaly creepy. What also passes:

>>> grid.y
array([0., 1., 0., 1., 0., 1., 0., 2.])

But not

>>> grid.y
array([0., 1., 0., 1., 0., 1., 0., 3.])

Or

>>> grid.y
array([0., 1., 0., 1., 0., 1., 0., -2.])

Approving this fix for now, but we should really get to the bottom of this.

[codecov]

Codecov Report

Merging #2511 (9db5e45) into main (9a79214) will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2511      +/-   ##
==========================================
+ Coverage   93.70%   93.77%   +0.06%     
==========================================
  Files          75       75              
  Lines       16072    16072              
==========================================
+ Hits        15061    15071      +10     
+ Misses       1011     1001      -10     

[adeak]

Oh wow, each item is allowed to have an absolute difference of 1 with respect to the true value:

>>> grid.x
array([-1., 2., -1., 2., -1., 2., -1., 2.])

☝️ this runs fine.

[MatthewFlamm]

Oh wow, each item is allowed to have a difference of 1 with respect to the true value:

>>> grid.x
array([-1., 2., -1., 2., -1., 2., -1., 2.])

☝️ this runs fine.

🤯 This is really really bad. I've found an MRE.

"""
Examples
--------
>>> import numpy as np
>>> np.array([0.])  # doctest: +NUMBER
array([1.])
"""

I wonder if this is why pytest-doctestplus disables the NUMBER directive?

[MatthewFlamm]

Also not limited to numpy arrays. Ouch.

"""
>>> [0.]  # doctest: +NUMBER
[1.]
"""

[adeak]

Also not limited to numpy arrays. Ouch.

At least that makes sense to me. The only thing here that makes sense to me 🙄

[MatthewFlamm]

Now that we can confirm that it isn't a pyvista specific issue, I think we are good to merge this. I will create an issue in pytest repo.

[MatthewFlamm]

To close the loop here, the NUMBER option does not just compare up to the precision given as indicated in the documentation. It uses pytest.approx to compare using the precision as the relative tol. So 1. and 0. are compared as 0. == approx(1., rel=1.). This results in evaluating to True.

If pytest chooses to keep this behavior, we should drop NUMBER as a by default doctest option. This case is unexpected and will be too common in this type of codebase.

[MatthewFlamm]

I always wondered why sometimes it seemed that our doctest was inconsistent on when it rounded numbers, and now I know why.