On 1/20/08, Paul Moore wrote:

Both of these are likely to be of limited use. The most common usage I know of is to make a "sensible" rational from a float (i.e., a DWIM style conversion 0.1 -> 1/10) or to provide readable output. On the other hand, both are subtle to implement, so having a standard implementation saves people having to code (and debug) their own.

I suspect that simplest within a particular distance is the form that is most often wanted, but I don't have any good evidence for that feeling. Putting both in might help people to realise that there *is* a choice.

Given that you have implemented them, I'd say leave them in. And I like the names trim and approximate, as given in the code you referenced.

I can't think of a use case for these either, but the first (limit_denominator) seems like a generalized round, and I suppose might be useful for something. -- Cheers, Leif

On 21/01/2008, Tim Peters wrote:

What would be useful is a method that generates (i.e., a generator in the Python sense) the (continued fraction) convergents to a rational. People wanting specific constraints on a rational approximation (including, but not limited to, the two you identified) can easily build them on top of such a generator.

Interesting. I thought of suggesting something like this, but my potential use cases are so rare that I couldn't justify it. But as you say, it's one general building block from which any other desired functionality can be produced.

By "useful" I don't mean lots of people will use it ;-) I mean /some/ people will use it -- a way to generate the sequence of convergents is a fundamental tool that can be used for all sorts of stuff, by those with advanced applications.

Good point. Fundamental tools belong in the library. +1 Paul.

On Jan 20, 2008 5:54 PM, Tim Peters wrote:

What would be useful is a method that generates (i.e., a generator in the Python sense) the (continued fraction) convergents to a rational. People wanting specific constraints on a rational approximation (including, but not limited to, the two you identified) can easily build them on top of such a generator.

I think that's significantly better than my two proposals. (Looking back at the issue, I see that Mark mentioned this possibility too and I just didn't understand him.) I'll plan on implementing that, along with the documentation Mark suggested, unless there are objections. Thanks! Jeffrey