Backport py3k float repr to trunk

[mdickinson]

BPO	7117
Nosy	@tim-one, @rhettinger, @amauryfa, @mdickinson, @vstinner, @ericvsmith, @voidspace
Files	round_fixup.patch: Backport of py3k round to trunk.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2009-11-25.10:41:11.777>
created_at = <Date 2009-10-13.08:30:24.826>
labels = ['interpreter-core', 'type-feature']
title = 'Backport py3k float repr to trunk'
updated_at = <Date 2011-06-30.11:17:01.710>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2011-06-30.11:17:01.710>
actor = 'vstinner'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-11-25.10:41:11.777>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2009-10-13.08:30:24.826>
creator = 'mark.dickinson'
dependencies = []
files = ['15254']
hgrepos = []
issue_num = 7117
keywords = ['patch']
message_count = 33.0
messages = ['93918', '94414', '94417', '94428', '94430', '94431', '94433', '94436', '94447', '94491', '94494', '94495', '94510', '94528', '94550', '94551', '94572', '94575', '94615', '94655', '94747', '94862', '95444', '95507', '95644', '95658', '95700', '95703', '95714', '139402', '139428', '139444', '139467']
nosy_count = 7.0
nosy_names = ['tim.peters', 'rhettinger', 'amaury.forgeotdarc', 'mark.dickinson', 'vstinner', 'eric.smith', 'michael.foord']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue7117'
versions = ['Python 2.7']

[mdickinson]

See the thread starting at:

http://mail.python.org/pipermail/python-dev/2009-October/092958.html

Eric suggested that we don't need a separate branch for this; sounds
fine to me. It should still be possible to do the backport in stages,
though. Something like the following?

(1) Check in David Gay's code plus necessary build changes,
configuration steps, etc; conversions still use the old code.

(2) Switch to using the new code for float -> string (str, repr, float
formatting) and string -> float conversions (float, complex
constructors, numeric literals in Python code). [Substeps?]

(3) Fix up builtin round function to use the new code.

(4) Make any necessary fixes to the documentation. (Raymond, I assume
you'll take care of the whatsnew changes when the time comes?)

(1), (3) and (4) should be straightforward. (2) is where most of the
work is, I think. I think it should be possible to do the stage (2)
work in pieces without breaking too much.

[mdickinson]

Some key revision numbers from the py3k short float repr, for reference:

r71663: include Gay's code, build and configure fixes
r71723: backout SSE2 detection code added in r71663
r71665: rewrite of float formatting code to use Gay's code

Backported most of r71663 and r71723 to trunk in:

r75651: Add dtoa.c, dtoa.h, update license.
r75658: configuration changes - detect float endianness,
add functions to get and set x87 control word, and
determine when short float repr can be used.

Significant changes from r71663 not yet included:

• Misc/NEWS update
• Lib/test/formatfloat_testcases.txt needs updating to match py3k.

[mdickinson]

r75666: Add sys.float_repr_style attribute.

[mdickinson]

r75672: temporarily disable the short float repr while we're putting
the pieces in place.

When testing, the disablement can be disabled (hah) by defining the
PY_SHORT_FLOAT_REPR preprocessor symbol, e.g. (on Unix) with

CC='gcc -DPY_SHORT_FLOAT_REPR' ./configure && make

[ericvsmith]

I think the next step on my side is to remove _PyOS_double_to_string,
and make all of the internal code call PyOS_double_to_string. The
distinction is that _PyOS_double_to_string gets passed a buffer and
length, but PyOS_double_to_string returns allocated memory that must be
freed. David Gay's code (_Py_dg_dtoa) returns allocated memory, so
that's the easiest interface to propagate internally.

That's the approach we used in the py3k branch. I'll start work on it.
So Mark's work should be mostly config stuff and hooking up Gay's code
to PyOS_double_to_string. I think it will basically match the py3k version.

The existing _PyOS_double_to_string will become the basis for the
fallback code for use when PY_NO_SHORT_FLOAT_REPR is defined (and it
will then be renamed PyOS_double_to_string and have its signature
changed to match).

[mdickinson]

One issue occurs to me: should the backport change the behaviour of the
round function?

In py3k, round consistently uses round-half-to-even for halfway cases.
In trunk, round semi-consistently uses round-half-away-from-zero (and
this is documented). E.g., round(1.25, 1) will give 1.2 in py3k and
(usually) 1.3 in trunk.

I definitely want to use Gay's code for round in 2.7, since having round
work sensibly is part of the motivation for the backport in the first
place. But this naturally leads to a round-half-to-even version of
round, since the Python-adapted version of Gay's code isn't capable of
doing anything other than round-half-to-even at the moment.

Options:

(1) change round in 2.7 to do round-half-to-even. This is easy,
natural, and means that round will agree with float formatting
(which does round-half-to-even in both py3k and trunk). But it
may break existing applications. However: (a) those applications
would need fixing anyway to work with py3k, and (b) I have little
sympathy for people depending on behaviour of rounding of
*binary* floats for halfway *decimal* cases. (Decimal is another
matter, of course: there it's perfectly reasonable to expect
guaranteed rounding behaviour.)

It's more complicated than that, though, since if rounding
becomes round-half-to-even for floats, it should also change
for integers, Fractions, etc.

(2) have round stick with round-half-away-from-zero. This may be
awkward to implement (though I have some half-formed ideas about
how to make it work), and would lead to round occasionally not
agreeing with float formatting. For example:

    >>> '{0:.1f}'.format(1.25)
    '1.2'
    >>> round(1.25, 1)
    1.3

[ericvsmith]

Adding tim_one as nosy. He'll no doubt have an opinion on rounding. And
hopefully he'll share it!

[ericvsmith]

Another thing to consider is that in py3k we removed all conversions of
converting 'f' to 'g', such as this, from Objects/unicodeobject.c:

if (type == 'f' && fabs(x) >= 1e50)
    type = 'g';

Should we also do that as part of this exercise? Or should it be another
issue, or not done at all?

[rhettinger]

+1 on backporting the 'f' and 'g' work also.
We will be well served by getting the two
code bases ins-sync with one another.

Eliminating obscure differences makes it easier
to port code from 2.x to 3.x

[mdickinson]

r75720: Backport py3k version of pystrtod.c to trunk. There are still
some (necessary) differences between the two versions, which
should become unnecessary once everything else is hooked up.
The differences should be re-examined later.

[mdickinson]

[Eric, on removing f to g conversions]

Should we also do that as part of this exercise? Or should it be another
issue, or not done at all?

I'd definitely like to remove the f to g conversion in trunk. I don't
see any great need to open a separate issue for that. (Was there one
already for the py3k removal?)

[mdickinson]

Found it: issue bpo-5859 was opened for the removal of the f -> g conversion
in py3k. We could just add a note to that issue.