Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent type-deduction of decimal floating-point #47610

Closed
richyk mannequin opened this issue Jul 15, 2008 · 7 comments
Closed

Inconsistent type-deduction of decimal floating-point #47610

richyk mannequin opened this issue Jul 15, 2008 · 7 comments
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@richyk
Copy link
Mannequin

richyk mannequin commented Jul 15, 2008

BPO 3360
Nosy @mdickinson

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 2008-07-16.11:05:04.020>
created_at = <Date 2008-07-15.10:45:36.528>
labels = ['interpreter-core', 'type-bug']
title = 'Inconsistent type-deduction of decimal floating-point'
updated_at = <Date 2008-07-16.11:05:03.997>
user = 'https://bugs.python.org/richyk'

bugs.python.org fields:

activity = <Date 2008-07-16.11:05:03.997>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2008-07-16.11:05:04.020>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2008-07-15.10:45:36.528>
creator = 'richyk'
dependencies = []
files = []
hgrepos = []
issue_num = 3360
keywords = []
message_count = 7.0
messages = ['69677', '69695', '69710', '69722', '69769', '69770', '69771']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'richyk']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3360'
versions = ['Python 2.5']

@richyk
Copy link
Mannequin Author

richyk mannequin commented Jul 15, 2008

When constructing a floating-point value, literals are apparently
sometimes interpreted as octal integral types, although they contain
exponent marker or/and decimal point. The presence of exponent marker
or/and decimal point should suffice to identify it as floating-point.

Example:
>>> x = 02120246124e0
>>> x = 02120246124.0
>>> x = 021202461241e0
ValueError: invalid literal for long() with base 8: '021202461241e0'
>>> x = 021202461241.0
ValueError: invalid literal for long() with base 8: '021202461241.0'

I am using Python 2.5.1 from openSuSE 10.3.

@richyk richyk mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jul 15, 2008
@mdickinson
Copy link
Member

I get the same behavior in the trunk (on OS X 10.5), though it's not a
problem in the py3k branch.

I agree that this is undesirable behaviour, and I think it should be
fixed. For me, the crossover seems to occur at 2*10**10:

>>> 020000000000.0
ValueError: invalid literal for long() with base 8: '020000000000.0'
>>> 019999999999.0
19999999999.0

@mdickinson mdickinson self-assigned this Jul 15, 2008
@mdickinson mdickinson added the type-bug An unexpected behavior, bug, or error label Jul 15, 2008
@richyk
Copy link
Mannequin Author

richyk mannequin commented Jul 15, 2008

Some additional information:

My original report was with an x86 system.

Now, I'm sitting in front of an x86_64 system running Python 2.4.4 (from
Debian stable) and Python 2.5.2 (from Debian testing), both 64 bit
userland. On these systems, the behavior I described does not exist:
Assignment always appears to result in an IEEE754 double-precision float.

@mdickinson
Copy link
Member

userland. On these systems, the behavior I described does not exist:

Not even with really large values? What happens on 64-bit with

>> x = 0800000000000000000000.0

? (that's 20 zeros between the 8 and the decimal point...)

@mdickinson
Copy link
Member

>  >>> x = 0800000000000000000000.0
Urk.  That should be:

>> x = 01000000000000000000000.0

The problem is in the parsenumber function in Python/ast.c. The
solution seems to be very simple: just remove the entire branch that
starts with
"if (s[0] == '0')"; that branch is clearly a holdover from pre-Python
2.4 days when some octal literals were supposed to produce a negative
int.

Now I just have to figure out where to add tests for this. Maybe there
should be a test_float_literal to parallel test_int_literal?

@mdickinson
Copy link
Member

Now I just have to figure out where to add tests for this.

Found it. Tests in test_compile.py.

Fixed in the trunk in r65005. This should probably also be backported to
2.5.

Thanks for the report, Richard!

@mdickinson
Copy link
Member

Fixed in the 2.5 branch, r65007.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

1 participant