[Python-ideas] Python-ideas Digest, Vol 103, Issue 3

Mon Jun 1 21:22:40 CEST 2015

Maybe we could make a C implementation of the Fraction module? That would
be nice.

On Sun, May 31, 2015 at 8:28 PM, <python-ideas-request at python.org> wrote:

> Send Python-ideas mailing list submissions to
>         python-ideas at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
>         python-ideas-request at python.org
>
> You can reach the person managing the list at
>         python-ideas-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
>    1. Re: Python Float Update (Chris Angelico)
>    2. Re: Python Float Update (random832 at fastmail.us)
>    3. Re: Python Float Update (Jim Witschey)
>    4. Re: Python Float Update (David Mertz)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 1 Jun 2015 12:48:12 +1000
> From: Chris Angelico <rosuav at gmail.com>
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Python Float Update
> Message-ID:
>         <CAPTjJmr=LurRUoKH3KVVYpMFc=
> W5h6etG5TscV5uU6zWhxVbgQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person
> <surya.subbarao1 at gmail.com> wrote:
> >
> > I will be presenting a modification to the float class, which will
> improve its speed and accuracy (reduce floating point errors). This is
> applicable because Python uses a numerator and denominator rather than a
> sign and mantissa to represent floats.
> >
> > First, I propose that a float's integer ratio should be accurate. For
> example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it
> returns(6004799503160661, 18014398509481984).
> >
>
> I think you're misunderstanding the as_integer_ratio method. That
> isn't how Python works internally; that's a service provided for
> parsing out float internals into something more readable. What you
> _actually_ are working with is IEEE 754 binary64. (Caveat: I have no
> idea what Python-the-language stipulates, nor what other Python
> implementations use, but that's what CPython uses, and you did your
> initial experiments with CPython. None of this discussion applies *at
> all* if a Python implementation doesn't use IEEE 754.) So internally,
> 1/3 is stored as:
>
> 0 <-- sign bit (positive)
> 01111111101 <-- exponent (1021)
> 0101010101010101010101010101010101010101010101010101 <-- mantissa (52
> bits, repeating)
>
> The exponent is offset by 1023, so this means 1.010101.... divided by
> 2?; the original repeating value is exactly equal to 4/3, so this is
> correct, but as soon as it's squeezed into a finite-sized mantissa, it
> gets rounded - in this case, rounded down.
>
> That's where your result comes from. It's been rounded such that it
> fits inside IEEE 754, and then converted back to a fraction
> afterwards. You're never going to get an exact result for anything
> with a denominator that isn't a power of two. Fortunately, Python does
> offer a solution: store your number as a pair of integers, rather than
> as a packed floating point value, and all calculations truly will be
> exact (at the cost of performance):
>
> >>> one_third = fractions.Fraction(1, 3)
> >>> one_eighth = fractions.Fraction(1, 8)
> >>> one_third + one_eighth
> Fraction(11, 24)
>
> This is possibly more what you want to work with.
>
> ChrisA
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 31 May 2015 23:14:06 -0400
> From: random832 at fastmail.us
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Python Float Update
> Message-ID:
>         <1433128446.31560.283106753.6D60F98F at webmail.messagingengine.com>
> Content-Type: text/plain
>
> On Sun, May 31, 2015, at 22:25, u8y7541 The Awesome Person wrote:
> > First, I propose that a float's integer ratio should be accurate. For
> > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it
> > returns(6004799503160661, 18014398509481984).
>
> Even though he's mistaken about the core premise, I do think there's a
> kernel of a good idea here - it would be nice to have a method (maybe
> as_integer_ratio, maybe with some parameter added, maybe a different
> method) to return with the smallest denominator that would result in
> exactly the original float if divided out, rather than merely the
> smallest power of two.
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 01 Jun 2015 03:21:36 +0000
> From: Jim Witschey <jim.witschey at gmail.com>
> To: Chris Angelico <rosuav at gmail.com>
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Python Float Update
> Message-ID:
>         <CAF+a8-q6kbOwcWk3F47+9PXf2vKgM9ao1uh5=qBw10jqzTC=
> kg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Teachable moments about the implementation of floating-point aside,
> something in this neighborhood has been considered and rejected before, in
> PEP 240. However, that was in 2001 - it was apparently created the same day
> as PEP 237, which introduced transparent conversion of machine ints to
> bignums in the int type.
>
> I think hiding hardware number implementations has been a success for
> integers - it's a far superior API. It could be for rationals as well.
>
> Has something like this thread's original proposal - interpeting
> decimal-number literals as fractional values and using fractions as the
> result of integer arithmetic - been seriously discussed more recently than
> PEP 240? If so, why haven't they been implemented? Perhaps enough has
> changed that it's worth reconsidering.
>
>
> On Sun, May 31, 2015 at 22:49 Chris Angelico <rosuav at gmail.com> wrote:
>
> > On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person
> > <surya.subbarao1 at gmail.com> wrote:
> > >
> > > I will be presenting a modification to the float class, which will
> > improve its speed and accuracy (reduce floating point errors). This is
> > applicable because Python uses a numerator and denominator rather than a
> > sign and mantissa to represent floats.
> > >
> > > First, I propose that a float's integer ratio should be accurate. For
> > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it
> > returns(6004799503160661, 18014398509481984).
> > >
> >
> > I think you're misunderstanding the as_integer_ratio method. That
> > isn't how Python works internally; that's a service provided for
> > parsing out float internals into something more readable. What you
> > _actually_ are working with is IEEE 754 binary64. (Caveat: I have no
> > idea what Python-the-language stipulates, nor what other Python
> > implementations use, but that's what CPython uses, and you did your
> > initial experiments with CPython. None of this discussion applies *at
> > all* if a Python implementation doesn't use IEEE 754.) So internally,
> > 1/3 is stored as:
> >
> > 0 <-- sign bit (positive)
> > 01111111101 <-- exponent (1021)
> > 0101010101010101010101010101010101010101010101010101 <-- mantissa (52
> > bits, repeating)
> >
> > The exponent is offset by 1023, so this means 1.010101.... divided by
> > 2?; the original repeating value is exactly equal to 4/3, so this is
> > correct, but as soon as it's squeezed into a finite-sized mantissa, it
> > gets rounded - in this case, rounded down.
> >
> > That's where your result comes from. It's been rounded such that it
> > fits inside IEEE 754, and then converted back to a fraction
> > afterwards. You're never going to get an exact result for anything
> > with a denominator that isn't a power of two. Fortunately, Python does
> > offer a solution: store your number as a pair of integers, rather than
> > as a packed floating point value, and all calculations truly will be
> > exact (at the cost of performance):
> >
> > >>> one_third = fractions.Fraction(1, 3)
> > >>> one_eighth = fractions.Fraction(1, 8)
> > >>> one_third + one_eighth
> > Fraction(11, 24)
> >
> > This is possibly more what you want to work with.
> >
> > ChrisA
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/python-ideas/attachments/20150601/5e792f59/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 31 May 2015 20:27:47 -0700
> From: David Mertz <mertz at gnosis.cx>
> To: random832 at fastmail.us
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Python Float Update
> Message-ID:
>         <
> CAEbHw4biWOxjYR0vtu8ykwSt63y9dcsR2-FtLPGfyUvqx0GgsQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sun, May 31, 2015 at 8:14 PM, <random832 at fastmail.us> wrote:
>
> > Even though he's mistaken about the core premise, I do think there's a
> > kernel of a good idea here - it would be nice to have a method (maybe
> > as_integer_ratio, maybe with some parameter added, maybe a different
> > method) to return with the smallest denominator that would result in
> > exactly the original float if divided out, rather than merely the
> > smallest power of two.
> >
>
> What is the computational complexity of a hypothetical
> float.as_simplest_integer_ratio() method?  How hard that is to find is not
> obvious to me (probably it should be, but I'm not sure).
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/python-ideas/attachments/20150531/49264b3d/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 103, Issue 3
> ********************************************
>

-- 
-Surya Subbarao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150601/694e9c92/attachment.html>