dgh@validgh.com (David G. Hough on validgh) (11/29/90)
There have been recent statements that functions like sqrt() are equivalent in Fortran and C. This is incorrect. In C, sqrt() is simply a function invocation. It has no known semantics unless #include <math.h> has been seen, in which case ANSI-C knows that it is a double-precision function of a double-precision argument. Thanks to the default conversions, you can use sqrt on float arguments with correct results, but they may take twice as long to compute as necessary if you really meant sqrtf(). sqrt() won't work on long double arguments unless long double == double. In Fortran, sqrt() is a generic intrinsic function, really an operator like +. Its semantics are known to the compiler. The precision of the sqrt operation can match that of the operand. As mentioned by others, ANSI-C defines exception handling for the sqrt() function and not for operators. On high-performance implementations, error checking, involving a conditional test and branch, can take as long as the sqrt operation itself, even if performed inline. System V implementations are worse, requiring an external call to matherr(), although this will be removed in a future version of SVID. -- David Hough dgh@validgh.com uunet!validgh!dgh na.hough@na-net.stanford.edu
henry@zoo.toronto.edu (Henry Spencer) (12/02/90)
In article <219@validgh.com> dgh@validgh.com (David G. Hough on validgh) writes: >There have been recent statements that functions like sqrt() are >equivalent in Fortran and C. This is incorrect. > >In C, sqrt() is simply a function invocation. It has no known >semantics unless #include <math.h> has been seen, in which case >ANSI-C knows that it is a double-precision function of a double-precision >argument... Unfortunately, this too is incorrect. In the absence of #include <math.h>, "sqrt" remains reserved for system use as an external name, and all bets are off if a program uses it for that purpose itself. (It can, however, be used as an internal-only name, e.g. a static function.) In the presence of #include <math.h>, it is *not* known to be a double-precision function of a double-precision argument; that is merely one of several possibilities. What is known is that you can call it as if it were one. It may well be a macro whose internals invoke compiler-specific magic, rather than a function invocation of any kind. >Thanks to the default conversions, you can use sqrt on float >arguments with correct results, but they may take twice as long to compute >as necessary if you really meant sqrtf(). There is no programming language that can remove the programmer's ultimate responsibility for efficient code. >sqrt() won't work on long double arguments unless long double == double. However, sqrtl() is reserved for future use for this purpose, and people supplying a useful `long double' type would presumably supply one. >In Fortran, sqrt() is a generic intrinsic function, really an operator like +. I don't recall this in the existing Fortran language (although I have not used Fortran 77 very much and might have missed it). If we're talking about future languages, like Fortran 20xx (called Fortran 9x by some optimists), the folks over in comp.lang.c++ can fill you in on a descendant of C, already in widespread use and in the works for standardization, which permits such things. >As mentioned by others, ANSI-C defines exception handling for the sqrt()... Now, *this* is a real issue, and one I'd forgotten about. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry