This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jyasskin facundobatista, gvanrossum, jyasskin, mark.dickinson, rhettinger 2008-01-18.04:28:45 0.028623732 No <1200630528.3.0.430139711238.issue1682@psf.upfronthosting.co.za>
Content
```After this come the two approximation methods. Both are implemented
using the continued fraction representation of the number:
http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations.
The first, currently named "trim", takes the closest rational whose
denominator is less than a given number. This seems useful for
computations in which you want to sacrifice some accuracy for speed. At
one point in this discussion, Guido suggested that Decimal removed the
need for a method like this, and this type isn't optimized for speed anyway.

The other, currently named "approximate", returns the "simplest"
rational within a certain distance of the real value. This seems useful
for converting from float and displaying results to users, where we
prefer readability over accuracy ("yes, I'll take '1/3' even though it's
farther away than '1234/3690'.").

We could provide 0, 1, or both of them, or an accessor for the continued
fraction representation of the number, which might help with third-party
implementations of both. I've never actually used either of these, so I
can't say which is actually more useful. It's probably a good question
to send to the full python-dev list. Even if we decide against including
them in the class, we might put the implementations into the docs or the
test as a demonstration.```
History
Date User Action Args
2008-01-18 04:28:48jyasskinsetspambayes_score: 0.0286237 -> 0.028623732
recipients: + jyasskin, gvanrossum, rhettinger, facundobatista, mark.dickinson
2008-01-18 04:28:48jyasskinsetspambayes_score: 0.0286237 -> 0.0286237
messageid: <1200630528.3.0.430139711238.issue1682@psf.upfronthosting.co.za>