stupid floating point question...
each unicode character has an optional "numeric value", which may be a fractional value. the unicodedata module provides a "numeric" function, which returns a Python float representing this fraction. this is currently implemented by a large switch stmnt, containing entries like: case 0x2159: return (double) 1 / 6; if I replace the numbers here with integer variables (read from the character type table) and return the result to Python, will str(result) be the same thing as before for all reasonable values? </F>
Try again? I have no idea what you're asking. Obviously, str(i) won't look anything like str(1./6) for any integer i, so *that's* not what you're asking.
-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On Behalf Of Fredrik Lundh Sent: Wednesday, September 27, 2000 5:42 PM To: python-dev@python.org Subject: [Python-Dev] stupid floating point question...
each unicode character has an optional "numeric value", which may be a fractional value.
the unicodedata module provides a "numeric" function, which returns a Python float representing this fraction. this is currently implemented by a large switch stmnt, containing entries like:
case 0x2159: return (double) 1 / 6;
if I replace the numbers here with integer variables (read from the character type table) and return the result to Python, will str(result) be the same thing as before for all reasonable values?
</F>
Try again? I have no idea what you're asking. Obviously, str(i) won't look anything like str(1./6) for any integer i, so *that's* not what you're asking.
consider this code: PyObject* myfunc1(void) { return PyFloat_FromDouble((double) A / B); } (where A and B are constants (#defines, or spelled out)) and this code: PyObject* myfunc2(int a, int b) { return PyFloat_FromDouble((double) a / b); } if I call the latter with a=A and b=B, and pass the resulting Python float through "str", will I get the same result on all ANSI-compatible platforms? (in the first case, the compiler will most likely do the casting and the division for me, while in the latter case, it's done at runtime) </F>
Fredrik Lundh wrote:
Try again? I have no idea what you're asking. Obviously, str(i) won't look anything like str(1./6) for any integer i, so *that's* not what you're asking.
consider this code:
PyObject* myfunc1(void) { return PyFloat_FromDouble((double) A / B); }
(where A and B are constants (#defines, or spelled out))
and this code:
PyObject* myfunc2(int a, int b) { return PyFloat_FromDouble((double) a / b); }
if I call the latter with a=A and b=B, and pass the resulting Python float through "str", will I get the same result on all ANSI-compatible platforms?
(in the first case, the compiler will most likely do the casting and the division for me, while in the latter case, it's done at runtime)
Casts have a higher precedence than e.g. /, so (double)a/b will be compiled as ((double)a)/b. If you'd rather play safe, just add the extra parenthesis. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Ah! I wouldn't worry about this -- go right ahead. Not only the str()'s, but even the repr()'s, are very likely to be identical. A *good* compiler won't collapse *any* fp expressions at compile-time, because doing so can change the 754 semantics at runtime (for example, the evaluation of 1./6 triggers the 754 "inexact" signal, and the compiler has no way to know whether the user is expecting that to happen at runtime, so a good compiler will leave it alone ... at KSR, I munged our C compiler to *try* collapsing at compile-time, capturing the 754 state before and comparing it to the 754 state after, doing that again for each possible rounding mode, and leaving the runtime code in if and only if any evaluation changed any state; but, that was a *damned* good compiler <wink>).
-----Original Message----- From: Fredrik Lundh [mailto:effbot@telia.com] Sent: Wednesday, September 27, 2000 6:00 PM To: Tim Peters; python-dev@python.org Subject: Re: [Python-Dev] stupid floating point question...
Try again? I have no idea what you're asking. Obviously, str(i) won't look anything like str(1./6) for any integer i, so *that's* not what you're asking.
consider this code:
PyObject* myfunc1(void) { return PyFloat_FromDouble((double) A / B); }
(where A and B are constants (#defines, or spelled out))
and this code:
PyObject* myfunc2(int a, int b) { return PyFloat_FromDouble((double) a / b); }
if I call the latter with a=A and b=B, and pass the resulting Python float through "str", will I get the same result on all ANSI-compatible platforms?
(in the first case, the compiler will most likely do the casting and the division for me, while in the latter case, it's done at runtime)
participants (3)
-
Fredrik Lundh
-
M.-A. Lemburg
-
Tim Peters