Message253211
> 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. |
|
Date |
User |
Action |
Args |
2015-10-20 06:44:40 | mark.dickinson | set | recipients:
+ mark.dickinson, benjamin.peterson, steven.daprano, josh.r, David MacIver, bar.harel |
2015-10-20 06:44:40 | mark.dickinson | set | messageid: <1445323480.63.0.859260712266.issue25177@psf.upfronthosting.co.za> |
2015-10-20 06:44:40 | mark.dickinson | link | issue25177 messages |
2015-10-20 06:44:39 | mark.dickinson | create | |
|