Author mark.dickinson
Recipients David MacIver, bar.harel, benjamin.peterson, josh.r, mark.dickinson, steven.daprano
Date 2015-10-20.06:44:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445323480.63.0.859260712266.issue25177@psf.upfronthosting.co.za>
In-reply-to
Content
> I strongly suspect that moving from float to Fraction-based ratios is going to kill performance in the common case

The existing code already converts each of the input items to Fraction; the only difference is that the old code converts the sum of those Fractions to float (or whatever the target type is) *before* dividing by the count, while the new code performs the sum/count division in Fraction-land, and only *then* converts to float.  That is, it's the difference between "float(exact_sum) / count" and "float(exact_sum / count)".

IOW, the performance is already dead.  Or rather, it's just resting: IIUC, the module design prioritises correctness over speed.  I'm sure Steven would be open to suggestions for faster algorithms that maintain the current accuracy.
History
Date User Action Args
2015-10-20 06:44:40mark.dickinsonsetrecipients: + mark.dickinson, benjamin.peterson, steven.daprano, josh.r, David MacIver, bar.harel
2015-10-20 06:44:40mark.dickinsonsetmessageid: <1445323480.63.0.859260712266.issue25177@psf.upfronthosting.co.za>
2015-10-20 06:44:40mark.dickinsonlinkissue25177 messages
2015-10-20 06:44:39mark.dickinsoncreate