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
Recipients facundobatista, gvanrossum, jyasskin, mark.dickinson, rhettinger
Date 2008-01-13.22:57:29
SpamBayes Score 0.00021916247
Marked as misclassified No
Message-id <1200265052.18.0.767384810556.issue1682@psf.upfronthosting.co.za>
In-reply-to
Content
_binary_float_to_ratio: Oops, fixed.

Rational() now equals 0, but I'd like to postpone Rational('3/2') until
there's a demonstrated need. I don't think it's as common a use as
int('3'), and there's more than one possible format, so some real world
experience will help (that is, quite possibly not in 2.6/3.0). I'm also
postponing Rational(instance_of_numbers_Rational).

+/-inf and nan are gone, and hash is fixed, at least until the next bug.
:) Good idea about using tuple.

Parentheses in str() help with reading things like
"%s**2"%Rational(3,2), which would otherwise format as "3/2**2". I don't
feel strongly about this.

Equality and the comparisons now work for complex, but their
implementations make me uncomfortable. In particular, two instances of
different Real types may compare unequal to the nearest float, but equal
to each other and have similar but inconsistent problems with <=. I can
trade off between false ==s and false !=s, but I don't see a way to make
everything correct. We could do better by making the intermediate
representation Rational instead of float, but comparisons are inherently
doomed to run up against the fact that equality is uncomputable on the
computable reals, so it's probably not worthwhile to spend too much time
on this.

I've added a test that float(Rational(long('2'*400+'7'),
long('3'*400+'1'))) returns 2.0/3. This works without any explicit
scaling on my part because long.__truediv__ already handles it. If
there's something else I'm doing wrong around here, I'd appreciate a
failing test case.

The open issues I know of are:
 * Is it a good idea to have both numbers.Rational and
rational.Rational? Should this class have a different name?
 * trim and approximate: Let's postpone them to a separate patch (I do
think at least one is worth including in 2.6+3.0). So that you don't
waste time on them, we already have implementations in the sandbox and
(probably) a good-enough explanation at
http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations.
Thanks for the offer to help out with them. :)
 * Should Rational.from_float() exist and with the current name? If
there's any disagreement, I propose to rename it to
Rational._from_float() to discourage use until there's more consensus.
 * Rational.from_decimal(): punted to a future patch. I favor this for
2.6+3.0.
 * Rational('3/2') (see above)

I think this is close enough to correct to submit and fix up the
remaining problems in subsequent patches. If you agree, I'll do so.
History
Date User Action Args
2008-01-13 22:57:32jyasskinsetspambayes_score: 0.000219162 -> 0.00021916247
recipients: + jyasskin, gvanrossum, rhettinger, facundobatista, mark.dickinson
2008-01-13 22:57:32jyasskinsetspambayes_score: 0.000219162 -> 0.000219162
messageid: <1200265052.18.0.767384810556.issue1682@psf.upfronthosting.co.za>
2008-01-13 22:57:31jyasskinlinkissue1682 messages
2008-01-13 22:57:29jyasskincreate