This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients asvetlov, pitrou, scoder, serhiy.storchaka, skrah, vstinner
Date 2016-09-02.14:48:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1472827724.05.0.863427733517.issue22458@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2016-09-02 14:48:44scodersetrecipients: + scoder, pitrou, vstinner, asvetlov, skrah, serhiy.storchaka
2016-09-02 14:48:44scodersetmessageid: <1472827724.05.0.863427733517.issue22458@psf.upfronthosting.co.za>
2016-09-02 14:48:44scoderlinkissue22458 messages
2016-09-02 14:48:43scodercreate