On Thu, Aug 1, 2013 at 10:44 AM, Oscar Benjamin
wrote:
> The real dividing line between {int, Fraction} and {float, Decimal,
> complex} is about (in)exactness. The numeric tower ensures the
> property that inexactness is contagious which I think is a good thing.
*nods slowly*
That does make sens
On 1 August 2013 07:32, Chris Angelico wrote:
> On Thu, Aug 1, 2013 at 7:20 AM, Steven D'Aprano
> wrote:
>> I know this, and that's not what surprised me. What surprised me was that
>> Fraction converts the float to a fraction, then compares. It surprises me
>> because in other operations, Fracti
On Thu, Aug 1, 2013 at 7:20 AM, Steven D'Aprano
wrote:
> I know this, and that's not what surprised me. What surprised me was that
> Fraction converts the float to a fraction, then compares. It surprises me
> because in other operations, Fractions down-cast to float.
>
> Adding a float to a Fracti
On Wed, 31 Jul 2013 15:23:21 -0500, Tony the Tiger wrote:
> On Mon, 29 Jul 2013 15:43:24 +, Steven D'Aprano wrote:
>
>> Am I the only one who is surprised by this?
>
> Most likely.
>
> Floats aren't precise enough to be equal to a (true) fraction.
> float(1/3) is cut short somewhere by the
On 7/29/2013 1:29 PM, Steven D'Aprano wrote:
On Mon, 29 Jul 2013 13:08:20 -0400, Terry Reedy wrote:
In other words, there can be multiple unequal Franctions that have the
same float value: for instance, Fraction(1,3) and
Fraction(6004799503160661, 18014398509481984)
> So from that standpoint
On Jul 29, 2013 1:37 PM, "Serhiy Storchaka" wrote:
>
> 29.07.13 19:09, MRAB написав(ла):
>
>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>> are approximate anyway, and the float value 1/3 is more likely to be
>> Fraction(1, 3) than Fraction(6004799503160661, 180143985094
On Mon, 29 Jul 2013 18:04:19 +0100, MRAB wrote:
> I thought that you're not meant to check for equality when using floats.
Heavens no. You're only meant to *mostly* not check for equality using
floats. As Miracle Max might say:
"It just so happens that floats are only MOSTLY inexact. There's a
On Mon, Jul 29, 2013 at 12:16 PM, Rotwang wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3.
>
>
> But the interpreter has no way of knowing that the value 1/3 that's been
> passed to the Fra
On Mon, 29 Jul 2013 17:20:27 +0100, Chris Angelico wrote:
Fraction(0.3)
> Fraction(5404319552844595, 18014398509481984)
Fraction(0.33)
> Fraction(5944751508129055, 18014398509481984)
[...]
Fraction(0.3)
> Fraction(6004799503160661, 18014398509481984)
>
> Rounding of
29.07.13 19:09, MRAB написав(ла):
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>>> def approximate_fraction(f):
prev_numer, numer
On 2013-07-29, MRAB wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
>>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float val
On 29/07/2013 17:20, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
On 29/07/2013 17:40, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3)
On Mon, Jul 29, 2013 at 11:04 AM, MRAB wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3. If it's some other float then
>> the user didn't get there by entering 1/3, so it's not worth trying
On Mon, 29 Jul 2013 13:08:20 -0400, Terry Reedy wrote:
> In other words, there can be multiple unequal Franctions that have the
> same float value: for instance, Fraction(1,3) and
> Fraction(6004799503160661, 18014398509481984)
>
> > So from that standpoint it makes sense to me to cast to Fracti
On Mon, 29 Jul 2013 17:48:21 +0100, MRAB wrote:
> On 29/07/2013 17:20, Chris Angelico wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB
>> wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely to be
>>> Fr
On Mon, Jul 29, 2013 at 5:40 PM, Ian Kelly wrote:
> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely
On 7/29/2013 11:50 AM, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 9:43 AM, Steven D'Aprano
wrote:
Comparing floats to Fractions gives unexpected results:
# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False
but:
py> 1/3 == float(Fraction(1, 3))
True
I expected that
On 29/07/2013 17:40, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3)
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
> On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>> are approximate anyway, and the float value 1/3 is more likely to be
>> Fraction(1, 3) than Fraction(6004799503160661,
On 29/07/2013 17:20, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
> are approximate anyway, and the float value 1/3 is more likely to be
> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
At what point should it become Fraction(
On 29/07/2013 16:43, Steven D'Aprano wrote:
Comparing floats to Fractions gives unexpected results:
# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False
but:
py> 1/3 == float(Fraction(1, 3))
True
I expected that float-to-Fraction comparisons would convert the Fract
On Mon, Jul 29, 2013 at 9:43 AM, Steven D'Aprano
wrote:
> Comparing floats to Fractions gives unexpected results:
>
> # Python 3.3
> py> from fractions import Fraction
> py> 1/3 == Fraction(1, 3)
> False
>
> but:
>
> py> 1/3 == float(Fraction(1, 3))
> True
>
>
> I expected that float-to-Fraction c
24 matches
Mail list logo
