Mark Dickinson dicki...@gmail.com added the comment:
(Slightly updated version of) patch applied in r71772 (trunk),
r71773 (py3k).
--
resolution: - accepted
stage: patch review - committed/rejected
status: open - closed
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
Updated patch; applies cleanly to current trunk. No significant changes.
Note that there's now a new reason to apply this patch: it ensures that
the result of a long-float conversion is independent of whether we're
using 30-bit digits or
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - marketdickinson
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3166
___
Mark Dickinson dicki...@gmail.com added the comment:
Updated patch; cleanup of comments and slight refactoring of code.
Int-float conversions are even a speck faster than the current code, for
small inputs. (On my machine, on a Friday night, during a full moon.
Your results may differ.
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file10694/long_as_double.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3166
___
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file12320/long_as_double2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3166
___
Mark Dickinson [EMAIL PROTECTED] added the comment:
Minor cleanup of long_as_double2.patch.
Added file: http://bugs.python.org/file12320/long_as_double2.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3166
Changes by Mark Dickinson [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12312/long_as_double2.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3166
___
STINNER Victor [EMAIL PROTECTED] added the comment:
float(295147905179352891391L) gives different result on Python 2.5 and
Python 2.6:
- 2.9514790517935289e+20 # Python 2.5.1
- 2.9514790517935283e+20 # 2.7a0
whereas the code is the same!?
___
Python
STINNER Victor [EMAIL PROTECTED] added the comment:
Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
reduce(lambda x,y: x*32768.0 + y, [256, 0, 0, 1, 32767])
2.9514790517935283e+20
float(295147905179352891391L)
2.9514790517935289e+20
Python 2.7a0 (trunk:67679M, Dec 9 2008, 14:29:12)
STINNER Victor [EMAIL PROTECTED] added the comment:
Ok, I understand why different versions of the same code gives
different results: compiler flags! Python 2.5.1 is my Ubuntu version
(should be compiled with -O3) whereas Python 2.7 and 3.1a0 are
compiled by me with -00.
Results with Python
Mark Dickinson [EMAIL PROTECTED] added the comment:
Victor, what does
1e16 + 2.
give on your Ubuntu 2.5 machine?
(Humor me. :) )
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3166
___
STINNER Victor [EMAIL PROTECTED] added the comment:
About -O0 vs -O1, I think that I understood (by reading the
assembler).
pseudocode of the -O0 version:
while ()
{
load x from the stack
x = x * ... + ...
write x to the stack
}
pseudocode of the -O1 version:
while
STINNER Victor [EMAIL PROTECTED] added the comment:
An interresting document: Request for Comments: Rounding in PHP
http://wiki.php.net/rfc/rounding
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3166
___
Mark Dickinson [EMAIL PROTECTED] added the comment:
Intel uses 80 bits float in internals, but load/store uses 64 bits
float. Load/store looses least significant bits.
Exactly. If your Intel machine is Pentium 4 or newer, you can get
around this by using the SSE2 extensions, which work with
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
On Tue, Dec 9, 2008 at 11:02 AM, Mark Dickinson [EMAIL PROTECTED] wrote:
...
If your Intel machine is Pentium 4 or newer, you can get
around this by using the SSE2 extensions, which work with 64-bit doubles
throughout. I don't
Mark Dickinson [EMAIL PROTECTED] added the comment:
[Alexander]
The flags you may be looking for are -msse2 -mfpmath=sse
Thanks, Alexander!
[Alexander again, from an earlier post...]
I noticed that you replaced a call to _PyLong_AsScaledDouble with your
round to nearest algorithm. I
Mark Dickinson [EMAIL PROTECTED] added the comment:
[Alexander]
I also wonder whether round to nearest float can be implemented
without
floating point arithmetics. I would think round towards zero should
be
a simple matter of extracting an appropriate number of bits from the
long and
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
..
The idea's attractive. The problem is finding an integer type that's
guaranteed to have enough bits to store the mantissa for the float
(probably plus one or two bits more for comfort); for IEEE 754 this
means a 64-bit integer
Changes by Gabriel Genellina [EMAIL PROTECTED]:
--
nosy: +gagenellina
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3166
___
___
Python-bugs-list
Mark Dickinson [EMAIL PROTECTED] added the comment:
As you say, performance would suffer.
What would using Python's integer type solve, that isn't already solved by
the patch?
I know the code isn't terribly readable; I'll add some comments
explaining clearly what's going on.
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
On Tue, Dec 9, 2008 at 12:39 PM, Mark Dickinson [EMAIL PROTECTED] wrote:
..
What would using Python's integer type solve, that isn't already solved by
the patch?
Speaking for myself, it would alleviate the irrational fear of
anything
Mark Dickinson [EMAIL PROTECTED] added the comment:
By the way, the algorithm here is essentially the same as the algorithm that I
implemented for the float.fromhex method, except that the float.fromhex method
is more
complicated in that it may have to deal with signed zeros or subnormals.
Mark Dickinson [EMAIL PROTECTED] added the comment:
Thanks for your comments, Alexander.
Here's a rewritten version of the patch that's better commented and
somewhat less convoluted; I think it should be easier to verify the
correctness of this one.
Added file:
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
Mark,
I noticed that you replaced a call to _PyLong_AsScaledDouble with your
round to nearest algorithm. I wonder if _PyLong_AsScaledDouble itself
would benefit from your change. Currently it is used in PyLong_AsDouble
and
Changes by STINNER Victor [EMAIL PROTECTED]:
--
nosy: +haypo
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3166
___
___
Python-bugs-list mailing list
STINNER Victor [EMAIL PROTECTED] added the comment:
You may use if (nbits == (size_t)-1 PyErr_Occurred()) to check
_PyLong_NumBits() error (overflow). Well, if (numbits DBL_MAX_EXP)
should already catch overflow, but I prefer explicit test to check the
error case.
Anyway, interresting
David Jones [EMAIL PROTECTED] added the comment:
I agree, longs should be correctly rounded when coerced to floats.
There is an ugly (but amusing) workaround while people wait for this
patch: Go via a string:
int(float(repr(295147905179352891391)[:-1]))
Though I assume this relies on the
New submission from Mark Dickinson [EMAIL PROTECTED]:
If n is a Python long, then one might expect float(n) to return the
closest float to n. Currently it doesn't do this. For example (with
Python 2.6, on OS X 10.5.2/Intel):
n = 295147905179352891391L
The closest float to n is equal to
29 matches
Mail list logo
