MAINT: No need to check for check for FPEs in casts to/from object #28358
Conversation
|
I’ll try to see if this fixes the test on my FreeBSD VM tomorrow since it looks like we’re out of compute credits. |
|
Ping @rgommers I think we have been out of credits for a little bit, could you recharge it some time? |
Done, sorry about that. Added 200 credits, that should last us 4-5 months at the current rate. |
|
@rgommers thanks! @ngoldbaum FWIW, I got the wrong place there (both places is fine) and CI is running now, so no need to check locally. |
|
I was actually in the middle of building NumPy in my VM to understand why the tests failed :) Thanks for following up. Assuming this fixes the tests let's close the other PR skipping the test on freebsd and merge this. |
seberg
force-pushed
the
no-fpes-in-obj-casts
branch
from
6462a1d to
ee5a6c2
Compare
Since these go via Python (in some form) and Python doesn't use FPEs we can be sure that we don't need to check for FPEs. Note that while it hides *almost always* spurious FPEs seen on some platforms, there could be certain chains or multiple cast situations where FPEs are checked for other reasons and the spurious FPE will show up. So it "somewhat": Closes numpygh-28351
I don't think it needs a comment that we can do this, but maybe it is nice to say that there was a reason for it.
seberg
force-pushed
the
no-fpes-in-obj-casts
branch
from
ee5a6c2 to
f3989bf
Compare
|
Thanks Sebastian. |
…umpy#28358) * MAINT: No need to check for check for FPEs in casts to/from object Since these go via Python (in some form) and Python doesn't use FPEs we can be sure that we don't need to check for FPEs. Note that while it hides *almost always* spurious FPEs seen on some platforms, there could be certain chains or multiple cast situations where FPEs are checked for other reasons and the spurious FPE will show up. So it "somewhat": Closes numpygh-28351 * MAINT: Follow-up, got the wrong place (the other is OK). * DOC: Add a small comment as per review request I don't think it needs a comment that we can do this, but maybe it is nice to say that there was a reason for it.
Since these go via Python (in some form) and Python doesn't use FPEs we can be sure that we don't need to check for FPEs.
Note that while it hides almost always spurious FPEs seen on some platforms, there could be certain chains or multiple cast situations where FPEs are checked for other reasons and the spurious FPE will show up.
So it "somewhat":
Closes gh-28351