On Aug 10, 2010, at 14:00, Michael Ash wrote:
> All operators with floating-point arguments must be performed with
> double precision. However, the C spec operates according to the
> "as-if" rule. The compiler is free to generate ANY code it wishes so
> long as the result is the same "as if" it were performed as the spec
> dictates. So in short, as long as your CPU's FPU does accurate 32-bit
> float calculations (and they usually do), the compiler can take
> something like this:
>
> floata = floatb * floatc;
>
> And compile it into code that does not ever promote to double, and
> still adhere to the standard.
Here's where I was going with this:
Although the above might be provably identical (given the CPU/FPU architecture)
to the spec-mandated calculation:
floata = (double) floatb * (double) floatc;
the following are not identical to each other numerically:
floata = atan (floatb) * atan (floatc);
floata = atanf (floatb) * atanf (floatc);
Therefore, switching from the double to the float versions of math.h functions
*for the purpose of eliminating compiler warnings about the size of the
variables* is slightly risky numerically, in a way that depends on the details
of the expression being calculated. 99 times out 100 in general purpose
programming the difference is irrelevant, but there is a potential danger.
I was just trying to make explicit the OP's unstated semi-premise that there's
no numerical issue there.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
