[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: I have started a discussion at https://discuss.python.org/t/allow-fractions-fraction-to-return-1-6-for-0-17-0-167-0-1667-etc . Your feedback there would be much appreciated. -- ___ Python tracker

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > I gave the code example in order to make that clear. Yep, that didn't help: reverse engineering the intended behaviour from a complicated piece of code isn't easy. An up-front description of the intended behaviour would be better. --

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: Re python-ideas: there's a mailing list: https://mail.python.org/archives/list/python-id...@python.org/ But the https://discuss.python.org/c/ideas/ category also works for this. -- ___ Python tracker

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: In case there are others who are unsure about "python-ideas" ... I believe the discussion page https://discuss.python.org/c/ideas is what was meant. -- ___ Python tracker

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > Please watch the tone. It is borderline abusive and dismissive. I apologize for the adverse impact there. I will be more careful. > Also, my expectation for Fraction("0.0015") would be to give Fraction(3, > 2000), the same as would be given by

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: Okay, let's close here; as Raymond says, that doesn't prevent further discussion on python-ideas. > The notions are currently too immature to warrant more core developer time. Agreed. It seems that what Lee wants is some kind of blend between the simplest

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Raymond Hettinger added the comment: > Nor will it achieve world peace. Please watch the tone. It is borderline abusive and dismissive. > we can invoke the attached as best_fraction(Fraction("0.001"), > Fraction("0.0005"), Fraction("0.0015")) to get the output > Fraction(1, 1000). -1 I am

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > The 12 semitones in an octave are separated ... Right, this functionality would not solve the semitones / cents problem. Nor will it achieve world peace. But if it solves enough use cases then it is worth discussing, yes? I haven't written the string

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Raymond Hettinger added the comment: Also note for the music example that the notion of "near enough" isn't equidistant about the "simple fraction". The sense of nearness is logarithmic and is measured in "cents" which are hundredths of an equal-tempered semitone (i.e a one octave consists

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Raymond Hettinger added the comment: I don't think the standard library should go down this path. Mark's disinclinations all make sense to me, but I'm also concerned that the API would be almost unusable in practical situations. Users would tend to know their input fraction and that they

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > What about for an input of "0.001"? Your current specification would give > 1/667, but I'm betting that you'd actually prefer 1/1000. You would win that bet. -- ___ Python tracker

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > I'd modify the optimization to be that we continue to seek the smallest > denominator, but in the case that multiple numerators would give ratios > within the computed interval then we choose the numerator among these that > gives the ratio closest to the

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: >It would return 1/7 for "0.1" and 1/4 for "0.2". Is it what you expected? I answered "yes" before, but I am now thinking "no". In the case of "0.1", the smallest numerator achievable is 1, but there are multiple denominators that would give a value within

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: The example of "16e2" would yield the interval [1550, 1650). The smallest denominator possible is 1. The smallest numerator that works with that denominator is 1550, but I don't like 1550/1 as the answer. To cover these edge cases, I'd modify the

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > One more example: what interval is implied by an input string of "1600"? Is > it (1550, 1650)? Or (1595, 1605)? Or even (1599.5, 1600.5). The rule would be to look at the last digit supplied and assume that the rounding is there. So "1600" gives [1599.5,

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > You may be interested in the "simplefractions" module on PyPI, which solves > the exact task "find the simplest fraction in a given interval". I haven't seen that code and I am interested; I will take a look. Perhaps code from there can be imported /

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: One more example: what interval is implied by an input string of "1600"? Is it (1550, 1650)? Or (1595, 1605)? Or even (1599.5, 1600.5). Sorry, I just don't see this working - there are two many arbitrary choices involved in guessing what interval the user

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > For another problematic example, suppose the string supplied is "0.10" We would treat "0.1", "0.10", "0.100", etc. all differently. In all cases we would assume rounding to compute the last digit. Similarly for "3e-10", "3.0e-10" == "30e-11", "3.00e-11",

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: > depending on which rounding mode was used (round-ties-to-even, > round-ties-to-away), the interval may be half-open, open or closed. I think we will get the majority of the use cases if we pick one rounding strategy and stick with it. In later version we

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: >It would return 1/7 for "0.1" and 1/4 for "0.2". Is it what you expected? Yes. Or putting it another way, if that's not the right answer then whoever rounded the number should have retained more digits. -- ___

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Lee Newberg added the comment: >This sounds interesting, but also rather similar to what the >`limit_denominator` method can get you. `Fractions("0.17").limit_denominator()` and `Fractions("0.17").limit_denominator(n)` for n > 28 do not give 1/6. So, I'd have to guess at n until I get

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: Sigh: > the next representable value up from 0.01 is 0.011 should say: > the next representable value up from 0.10 is 0.11 I think I'll duck out and give my brain a rest before commenting further. -- ___ Python

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > in which case the interval we need is [0.095, 0.15] Whoops, sorry; brain fail. If we're rounding to two sig figs, the next representable value up from 0.01 is 0.011, while the next one down is 0.099, so the interval we'd be interested in would be [0.0995,

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > the constructed Fraction first computes the range of the values that the > input string could have been rounded from There's too much magic and guesswork here for my liking; I don't really see this as feasible. Moreover, depending on which rounding mode

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Serhiy Storchaka added the comment: It would return 1/7 for "0.1" and 1/4 for "0.2". Is it what you expected? -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Zachary Ware added the comment: This sounds interesting, but also rather similar to what the `limit_denominator` method can get you. Can you provide examples that can't be handled nicely by `limit_denominator` to strengthen your case? -- nosy: +mark.dickinson, rhettinger, zach.ware

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

New submission from Lee Newberg : For example, a string such as "0.167" could be rounded from anything in [0.1665, 0.1675). Within that interval, the fraction with the lowest numerator and denominator is 1/6. Here it is proposed that we add a new flag to the Fractions constructor, perhaps