TST: Compat with numpy 1.25.dev - #14718

Might point to a subtle bug deep within modeling bounding box machinery? 🤷

Probably an unfortunate rounding error; still, not nice!

Yeah, if someone knows how to properly fix it in Gaussian2D, that would be better.

I think the fix has to be here somewhere:

I guess a more hacky alternative is to modify the test case so this won't happen for that test but it is not a real fix.

I guess it really depends on the goal of the test.... If it was just a sanity check that basically the box was the same, with a slop of 1 pixel due to rounding allowed, then it would be fine to adjust it. But I don't know...

The part of the test which is failing has nothing to do with the precise construction of the bounding box... Nor does it have anything to do with checking "if the box was the same"... Nor can it be the result of a "rounding error"..

The point of the test where it is failing is showing that a model properly discriminates if the inputs are inside/outside the bounding box when integrated into the model evaluation process.

It specifically constricts two sets of inputs x1, y1, x2, y2 such that:

1. All the points in x1, y1 are in x2, y2 respectively
2. All points in x2, y2 not in x1, y1 lie outside the bounding box

The model is then evaluated on these points without/with bounding box enforcement respectively (to x1, y1 vs x2, y2). This means that all the outputs corresponding to points outside the bounding box should be set to np.NaN. Consequently, due to the specific construction of x2, y2 relative to x1, y1 it should be the case that all the non np.NaN outputs of both evaluations should exactly correspond without any rounding errors (it is literally an exactly repeated computation).

To see that the assumptions should be satisfied, note that (1) is satisfied by

While (2) is satisfied by the fact that the bounding box limits are used and the additional points are all created strictly -/+idx*ddx where idx != 0, where -/+ is with respect to the lower/upper bounds of the bounding box. This implies that all the additional points are strictly outside the bounding box. There should be no rounding error issues ddx = .01, which is much much larger than machine precision (so well outside any rounding error concerns).

Since bounding boxes discriminate the input points lying outside the box using

Note that, the error in question:

ValueError: operands could not be broadcast together with shapes (1100,) (1099,)

Indicates that some point in x1, y1 is being evaluated to np.NaN in the x2, y2 computation. There are a few possibilities:

1. The bounding box incorrectly discriminating on the endpoints of the bounding box as those points are specifically included in the computation. Meaning there is an issue with the > or < comparisons in the outside method.
2. Some sort of new numerical issue is causing a np.NaN occur when evaluating Gaussian2D on points contained within its bounding box (this is surprising since the default bounding box for Gaussian2D is selected specifically so that no numerical errors should occur when evaluating on points contained within it).
3. There is an issue with

   astropy/astropy/modeling/tests/test_models.py

   Line 253 in e3b2444

   outside_bbox = outside_bbox[~np.isnan(outside_bbox)]

   wherein ~np.isnan(...) is incorrectly flagging a non-np.NaN value as NaN.

The way I could distinguish between these possibilities would be

1. Compare inside_bbox with inside_bbox[~np.isnan(inside_bbox)] (eliminates/confirms possibility (2))
2. and/or Compute inside_bbox with the with_bounding_box=True option (eliminates/confirms possibility (1))
3. Manually examine the raw values of inside_bbox and outside_bbox (eliminates/confirms possibility (3))

However, I can no-longer reproduce this issue, see #14771 so I cannot exactly determine the cause.

Probably an unfortunate rounding error; still, not nice!

This "fix" is far far too aggressive. The only issue here is with numpy 1.25.dev and at the very least this should be restricted to that case only. As it stands, this "fix" turns off testing in all cases.

Thanks for the follow up fix of this "fix"!