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-11.20:50:32
SpamBayes Score 0.013824525
Marked as misclassified No
Message-id <>
If the consensus is that Decimal should not implement Real, I'll reply
to that thread and withdraw the patch.

Raymond, do you want me to add Decimal.__init__(Rational) in this patch
or another issue/thread?

I don't understand the comment about scaling down long integers. It's
already the case that float(Rational(10**23, 10**24 + 7))==0.1.

Mark, I agree that .trim() and/or .approximate() (which I think is the
same as Haskell's approxRational) would be really useful. Do you have
particular reasons to pick .trim? Are those the best names for the
concepts? I'd also really like to be able to link from their docstrings
to a proof that their implementations are correct. Does anyone know of one?

Finally, Decimal("2.5") != Rational(5, 2) because Decimal("2.5") != 2.5
(so it'd make equality even more intransitive) and hash(Decimal("2.5"))
!= hash(2.5) so we couldn't follow the rule about equal objects implying
equal hash codes, which is probably more serious. I don't have a
principled explanation for Decimal's behavior, but given that it's
fixed, I think the behavior of non-integral Rationals is determined too.
On the other hand, I currently have a bug where Rational(3,1) !=
Decimal("3") where the hash code could be consistent. I'll fix that by
the next patch.
Date User Action Args
2008-01-11 20:50:33jyasskinsetspambayes_score: 0.0138245 -> 0.013824525
recipients: + jyasskin, gvanrossum, rhettinger, facundobatista, mark.dickinson
2008-01-11 20:50:33jyasskinsetspambayes_score: 0.0138245 -> 0.0138245
messageid: <>
2008-01-11 20:50:32jyasskinlinkissue1682 messages
2008-01-11 20:50:32jyasskincreate