Mark Dickinson <dicki...@gmail.com> added the comment: The big mystery for me is not "Why this is occurring in the first place?" but "What should we do about it?"
I'm really reluctant to (even conditionally) skip the test, because it's doing exactly what it's designed to do, namely detecting and reporting that Python is giving poor results in this corner case on this platform. As developers, we can blame the poor results on the platform's libm, but that doesn't help the user. If we can find combinations of compiler flags that fix the issue for this platform, then I guess that's a solution. But what if we can't? Do we simply accept that the test suite will fail on this platform (and perhaps add a visible comment somewhere that this is a known issue, with a link to this bpo issue)? We can certainly hack together a tan implementation that behaves better in these corner cases; it's not totally trivial, but not all that hard, either (I suspect that simply using `sin / cos` would already be an improvement.) But if we do this every time we encounter a platform-specific libm corner case, we'll end up with a maze of twisty windy workarounds in mathmodule.c ... Or we could drop the fine-grained math library tests altogether: if the purpose of the math module is to wrap the platform libm and return the results it's returning, then we're already doing that perfectly well, so the tests are at best useless, and at worst problematic in cases like this. But I'm not so happy with that solution either. Thoughts? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31630> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
