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)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4