Send Python-ideas mailing list submissions to
python-ideas@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@python.org
You can reach the person managing the list at
python-ideas-owner@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@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@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Python Float Update
Message-ID:
<CAPTjJmr=LurRUoKH3KVVYpMFc=W5h6etG5TscV5uU6zWhxVbgQ@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@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@fastmail.us
To: python-ideas@python.org
Subject: Re: [Python-ideas] Python Float Update
Message-ID:
<1433128446.31560.283106753.6D60F98F@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@gmail.com>
To: Chris Angelico <rosuav@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Python Float Update
Message-ID:
<CAF+a8-q6kbOwcWk3F47+9PXf2vKgM9ao1uh5=qBw10jqzTC=kg@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@gmail.com> wrote:
> On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person
> <surya.subbarao1@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@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@gnosis.cx>
To: random832@fastmail.us
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Python Float Update
Message-ID:
<CAEbHw4biWOxjYR0vtu8ykwSt63y9dcsR2-FtLPGfyUvqx0GgsQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, May 31, 2015 at 8:14 PM, <random832@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
------------------------------
End of Python-ideas Digest, Vol 103, Issue 3
********************************************