The fun part is, that this was quite for off even before if a machine at AVX512 (typically one less ULP, but that if would be randomly wrong on such a machine in a range where it should round to 1!

The linked PR is the wrong one, that just fixes a small unrelated issue, gh-23399 is the relevant one and has more discussion, also ping @Mousius.

TBH, I would prefer higher precision around these special values, and that includes the old SVML fallback (which not super many users end up with anyway). This is all very hard to make clear cut calls on though, since I also think a check like the one you said is dubious.

(I also am surprised that the functions are non-monotenous, TBH. For these fast vectorized algorithms at least, results fluctuate randomly by 1-2 ULPs in regions where they should be numerically constant.)

The linked PR is the wrong one

For closure, I identified #23695 as the cause using git bisect, which lead to c43ae85

#23399 indeed provides much more context, thank you !
Seeing that astropy and SciPy already adapted to the change and that, even on already released versions of numpy np.sin(np.pi) != 0, I'm all the more tempted to just handle it downstream.

I am not sure that np.sin(np.pi) != 0 happened before in any context. However np.sin(np.pi+eps) != 0 did happen for sure, which isn't any better probably :).

The question is whether a pattern of a decent fraction of large scientific downstream packages noticing this (most will only test after the release), should worry us...

I am not sure that np.sin(np.pi) != 0 happened before in any context.

I'm getting 1.2246467991473532e-16 with numpy 1.23.4 on macOS. This was also noted in #23399 (comment)

Is this issue still open? Happy to pick up if not worked on yet

@bb-ssaxena99 It's more of a policy discussion, not a work item at this time. Check the sprintable label for issues that are better for new contributors to work on.

I guess the discussion may not be over, but for this specific issue it is (its precise in 1.25 for the moment and maybe its more likely we go the context manager opt-in route, or maybe not...).