This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2013年04月29日 03:29 by squeakbat, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| math.py | squeakbat, 2013年04月29日 03:29 | |||
| Messages (7) | |||
|---|---|---|---|
| msg188033 - (view) | Author: Ellen Wang (squeakbat) | Date: 2013年04月29日 03:29 | |
This is only on a PowerPC, specifically a p2020, running Debian 7.0 wheezy, python 2.7.3. Calling round() seems to corrupt something (in the floating point state?) that causes subsequent exponentiation (the ** operator) to be wrong: Python 2.7.3 (default, Jan 2 2013, 16:38:11) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 2 ** -2 0.25 >>> round(1) 1.0 >>> 2 ** -2 0.1253019036571362 Cool. Huh? |
|||
| msg188034 - (view) | Author: Ellen Wang (squeakbat) | Date: 2013年04月29日 03:57 | |
Here's an example that uses only math library functions and float literals, presumably with a simpler code path: Python 2.7.3 (default, Jan 2 2013, 16:38:11) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> math.exp(-2.0) 0.1353352832366127 >>> math.ceil(1.0) 1.0 >>> math.exp(-2.0) 0.23902241864785234 By the way, the equivalent C program (using exp() and ceil()) on the same platform behaves correctly, so it's not an obvious libc or fpu problem. |
|||
| msg188039 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) | Date: 2013年04月29日 07:13 | |
I can't reproduce this on 2.7.4. Could you please test 2.7.4? |
|||
| msg188040 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2013年04月29日 07:21 | |
Hmm: it's not an obvious Python bug, either: both math.exp and math.ceil are simple wrappers around the libm functions, so there's little room for things to go wrong between Python and the OS. Are you in a position to compile Python from source on your platform? What was the equivalent C program you tried? What's the compiler on this platform? Note that gcc (I believe) evaluates math function calls for constants at compile time (using MPFR), rather than run time, which would mean if your C program simply does "exp(-2.0);" then it's not even using the OS libm. |
|||
| msg188042 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) | Date: 2013年04月29日 07:23 | |
Oh, sorry, I missed PowerPC. Please ignore my previous comment. |
|||
| msg188044 - (view) | Author: Ellen Wang (squeakbat) | Date: 2013年04月29日 07:26 | |
OK. My bad. I should have been tipped off that the program didn't need -lm to link. Output from C code: 0.135335 1 0.239022 Feel free to close. I'll have to look into this on my own. Thanks and sorry. |
|||
| msg188048 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2013年04月29日 08:36 | |
No problem; thanks for the update. By the way, if you do file an OS bug report of some form, it would be great if you could add a link to this issue. That might help anyone who encounters this in Python in the future. Closing. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:45 | admin | set | github: 62065 |
| 2013年04月29日 08:36:45 | mark.dickinson | set | status: open -> closed resolution: works for me messages: + msg188048 |
| 2013年04月29日 07:26:34 | squeakbat | set | messages: + msg188044 |
| 2013年04月29日 07:23:23 | serhiy.storchaka | set | messages: + msg188042 |
| 2013年04月29日 07:21:10 | mark.dickinson | set | messages: + msg188040 |
| 2013年04月29日 07:13:31 | mark.dickinson | set | nosy:
+ mark.dickinson |
| 2013年04月29日 07:13:04 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka messages: + msg188039 |
| 2013年04月29日 03:57:10 | squeakbat | set | messages: + msg188034 |
| 2013年04月29日 03:29:26 | squeakbat | create | |