PR Summary

As was discussed in#17090, the semantics ofBbox.null are very unexpected.

While it is supposed to represent the empty set, it currently has pretty surprising behavior under intersection and union (which, in particular, does not correspond to the behavior of the empty set).

This is because union and intersection are currently implemented by comparingxmin andxmax instead ofx0 andx1 (respectively,ymin, ...etc.).

This PR corrects the semantics of Bboxs so that they are a ring of sets, with a unique null set (Bbox.null()) as an additive identity and a unique multiplicative identity (Bbox.unbounded()).

This is a major change that fundamentally changes how Bbox's work, and I will need to do some digging to ensure it doesn't break anything internally. However, so far I don't see any substantive issues in the test suite, just a few cases where axes bounds relied on the previous buggy behavior, all look like simple fixes.

Implementation details

In order to change as little code as possible, and maintain keep any API change as unsurprising as possible, I kept the existing representation of the empty set,Bbox([[inf, inf], [-inf, -inf]]).

In order to fixintersection andunion, they should simply follow the well-established formulas:

and

It is easy to check that the existing representation of the empty set (Bbox.null) produces the correct behavior in both of these formulas.

However, there definitely can be produce pathological behavior if we allow "improper" intervals of the form$[b, a]$ for$b > a$.

After experimenting for some time with the algebraic properties of these improper intervals, I concluded that and are simply not well defined in these cases. Our existing behavior is almost definitely a bug, for example, while the following intersection returns the (reasonable) reply of "None":

>>> Bbox.intersection(Bbox([[2, 2], [1, 1]]), Bbox([[0, 0], [-1, -1]]))>>>

The "union" operator currently finds the Bbox by something equivalent to
update_from_data_xy(np.stack([bbox.get_points() for bbox in bboxes]), ignore=True):

>>> Bbox.union([Bbox([[2, 2], [1, 1]]), Bbox([[0, 0], [-1, -1]])])Bbox([[-1.0, -1.0], [2.0, 2.0]])

This is almost certainly not I would want to happen, as it means that the union of two empty Bboxs can create a Bbox that's not empty. But I could see how existing code might abuse this fact...

Deprecation schedule

Since the existing intersection and union results might be used by quite a bit of code, (even internally), I assume any deprecation schedule should be commensurately conservative.

The "3.4" in this PR is more of a placeholder in order to allow discussion than anything else.

PR Checklist

• Has Pytest style unit tests
• Code isFlake 8 compliant
• New features are documented, with examples if plot related
• Documentation is sphinx and numpydoc compliant
• Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way