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

[BUG]: Shift box_aspect according to vertical_axis #28041

Merged
merged 19 commits into from
Jun 2, 2024
Merged
Show file tree
Hide file tree
Changes from 9 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 3 additions & 3 deletions lib/mpl_toolkits/mplot3d/axes3d.py
Original file line number Diff line number Diff line change
Expand Up @@ -383,7 +383,7 @@ def set_box_aspect(self, aspect, *, zoom=1):
# of the axes in mpl3.8.
aspect *= 1.8294640721620434 * 25/24 * zoom / np.linalg.norm(aspect)

self._box_aspect = aspect
self._box_aspect = self._roll_to_vertical(aspect, sign=-1)
self.stale = True

def apply_aspect(self, position=None):
Expand Down Expand Up @@ -1190,9 +1190,9 @@ def set_proj_type(self, proj_type, focal_length=None):
f"None for proj_type = {proj_type}")
self._focal_length = np.inf

def _roll_to_vertical(self, arr):
def _roll_to_vertical(self, arr, sign=1):
Copy link
Member

Choose a reason for hiding this comment

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

The naming sign is purely technical but does not explain what it's doing.

Suggested change
def _roll_to_vertical(self, arr, sign=1):
def _roll_to_vertical(self, arr, reverse=False):
"""
Roll arrays to match the different vertical axis.
If *reverse*, perform the inverse operation.
"""

"""Roll arrays to match the different vertical axis."""
return np.roll(arr, self._vertical_axis - 2)
return np.roll(arr, sign * (self._vertical_axis - 2))

def get_proj(self):
"""Create the projection matrix from the current viewing position."""
Expand Down
17 changes: 17 additions & 0 deletions lib/mpl_toolkits/mplot3d/tests/test_axes3d.py
Original file line number Diff line number Diff line change
Expand Up @@ -2250,6 +2250,23 @@ def test_view_init_vertical_axis(
np.testing.assert_array_equal(tickdir_expected, tickdir_actual)


@pytest.mark.parametrize("vertical_axis", ["x", "y", "z"])
def test_set_box_aspect_vertical_axis(vertical_axis: str) -> None:
ax = plt.subplot(1, 1, 1, projection="3d")
ax.view_init(elev=0, azim=0, roll=0, vertical_axis=vertical_axis)
ax.figure.canvas.draw()

aspect_old = tuple(ax._box_aspect)
aspect_expected = np.roll(
aspect_old, -1 * (ax._axis_names.index(vertical_axis) - 2)
)

ax.set_box_aspect(None)
aspect_new = tuple(ax._box_aspect)

np.testing.assert_allclose(aspect_expected, aspect_new)
Copy link
Member

Choose a reason for hiding this comment

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

Does this test have semantic meaning? I can't see by itself that aspect_expected is expected to be as defined by the roll operation. To me it appears that this formular was just copied from set_box_aspect, which would be tautological ("set_box_aspect behaves according to the formula given in set_box_aspect") and doesn't actually prove anything. Also note that the first two entries of the default box aspect (None -> (4, 4, 3)) are identical. This reduces test power because we cannot distinguish whether they are mixed up or not.

I think there are two ways to make this better: Either

  • Use explicit expectations. Something like (not checked the numbers and the exact logic):
    ax.view_init(elev=0, azim=0, roll=0, vertical_axis="x")
    ax.set_box_aspect((1, 2, 3))  # (x, y, z)
    np.testing.assert_allclose)(ax._box_aspect, (2, 3, 1))  # (width, depth, height)
    
    or
  • use an image comparison test and compare rotated views with permuted box_aspects.



@image_comparison(baseline_images=['arc_pathpatch.png'],
remove_text=True,
style='mpl20')
Expand Down