Stefan Behnel added the comment: > So this benchmark cannot be used to show the superiority of exact fractions.
I don't see how a benchmark would be a way to show that. It's certainly not the goal of this benchmark to show that one is computationally better than the other. But if a benchmark for one part of Python allows a direct, reasonable speed comparison with another, why would you object to make use of that? > is the purpose of this benchmark to show that fractions are slow and generate > interest in changing the situation? There have been a couple of attempts to make them faster already. The speed improvements in Py3.5 and 3.6 directly result from those changes. Thus, making these improvements visible and comparable across Python versions and different implementations is one of the goals of this benchmark. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22458> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
