[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: For the record: making a public math.as_integer_ratio() function was rejected at #37822. -- ___ Python tracker ___

[issue37884] Optimize Fraction() and statistics.mean()

Steven D'Aprano added the comment: On Sat, Aug 24, 2019 at 10:09:40AM +, Serhiy Storchaka wrote: > Could you please explain what is wrong in adding a helper function > which will help to convert different types of numbers to integer ratio > correctly? > > Currently you need to write a

[issue37884] Optimize Fraction() and statistics.mean()

Serhiy Storchaka added the comment: > I'm with Raymond here; I don't think this change is desirable for the math > module, either with or without the leading underscore in the name. Could you please explain what is wrong in adding a helper function which will help to convert different types

[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: > FWIW, the entire point of us having recently added as_integer_ratio() methods > to so many concrete classes is to avoid the need for helper functions in > favor of a simple try/except around a single call. But what about PEP 3141? The fractions.Fraction

[issue37884] Optimize Fraction() and statistics.mean()

Raymond Hettinger added the comment: [Mark] > I'm with Raymond here; I don't think this change is > desirable for the math module, either with or without > the leading underscore in the name. [Jeroen] > May I propose PR 15327 as alternative? I'll take a look soonish. Since it has its own

[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: May I propose PR 15327 as alternative? It solves some of the same issues as the PR on this issue, in particular supporting arbitrary objects with as_integer_ratio(). It also improves performance somewhat for certain inputs, but that's more by accident.

[issue37884] Optimize Fraction() and statistics.mean()

Mark Dickinson added the comment: > This issue if for optimization only. It does not expand the math module API. I think it does, though. The PR adds something to the math module that's tested, that needs to be maintained for other modules to work, and that's imported for use in another

[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: > our needs tend to be much different from end-users This issue is about fractions and statistics, which are closer to typical user libraries than CPython libraries. In fact, both could easily be packages on PyPI instead of part of the standard library. >

[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: > AFAICT, no end-user has ever requested this ever. What do you mean with "this"? (A) A public function like math.as_integer_ratio() (B) Using as_integer_ratio() in the fractions.Fraction() constructor (C) The optimization of the fractions.Fraction()

[issue37884] Optimize Fraction() and statistics.mean()

Raymond Hettinger added the comment: AFAICT, no end-user has ever requested this ever. Despite your insistence, we really don't have to clutter the math module with this. We sometimes do have two or three repetitions of logic in the standard library; however, our needs tend to be much

[issue37884] Optimize Fraction() and statistics.mean()

Serhiy Storchaka added the comment: This issue if for optimization only. It does not expand the math module API. Adding public math.as_integer_ratio() has other benefits (it allows to simplify the user code), but it is a different issue (see issue37822). --

[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: > ISTM that small and probably unimportant opimizations shouldn't spill-over > into API feature creep. The way I see it, the optimization is besides the point here. Regardless of performance, the added function is a useful feature to have to avoid forcing

[issue37884] Optimize Fraction() and statistics.mean()

Raymond Hettinger added the comment: Mark, I don't think the math module API should be expanded for as_integer_ratio(). ISTM that small and probably unimportant opimizations shouldn't spill-over into API feature creep. What do you think? -- assignee: -> mark.dickinson

[issue37884] Optimize Fraction() and statistics.mean()

Jeroen Demeyer added the comment: > There is a 14% regression in creating a Fraction from an integer Isn't that the main use case? I suggest to keep the special case for 'int' as fast path to avoid this regression. -- nosy: +jdemeyer ___ Python

[issue37884] Optimize Fraction() and statistics.mean()

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +15047 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15329 ___ Python tracker

[issue37884] Optimize Fraction() and statistics.mean()

New submission from Serhiy Storchaka : The proposed PR optimizes the Fraction constructor and statistics.mean() (and several other statistics functions) by using a private helper implemented in C which abstracts converting a number to an integer ratio. $ ./python -m timeit -s "from fractions