Home > Archive > Fortran > September 2005 > Re: why system providing routies will provide different result in
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: why system providing routies will provide different result in
|
|
| Tim Prince 2005-09-13, 3:57 am |
| Ian Chivers wrote:
> c/c++ built in maths functions will convert/promote any argument to double
> and
> return a double result.
This is true of "traditional" C and C++. Most C++ compilers support
versions corresponding to the various floating point data types.
C differs from C++ in supporting "type generic" intrinsic functions
<tgmath.h>, somewhat analogous to Fortran. Many C++ compilers support
mixing it in as an extension. OP may have meant to exclude it by
specifying C++.
>
> literal numeric constants (e.g. 2.0) in fortran are c++ float.
> in c++ they are double.
>
I agree that the difference in default types (double in C++, commonly
single in Fortran) is among the issues OP should be considering.
It is not unusual for C and Fortran to share the math function library,
in which case difference in results is attributable to cockpit error.
| |
| glen herrmannsfeldt 2005-09-13, 3:57 am |
| Tim Prince wrote:
> Ian Chivers wrote:
[color=darkred]
> This is true of "traditional" C and C++.
You mean like C89? How many C99 compilers do you know of?
About as many as F2003 compilers?
> Most C++ compilers support
> versions corresponding to the various floating point data types.
> C differs from C++ in supporting "type generic" intrinsic functions
> <tgmath.h>, somewhat analogous to Fortran. Many C++ compilers support
> mixing it in as an extension. OP may have meant to exclude it by
> specifying C++.
[color=darkred]
> I agree that the difference in default types (double in C++, commonly
> single in Fortran) is among the issues OP should be considering.
Well, the default type in C is int in the cases where it
matters. Otherwise variables have to be declared either double
or float.
> It is not unusual for C and Fortran to share the math function library,
> in which case difference in results is attributable to cockpit error.
Yes. Or even the whole C library.
-- glen
| |
| Tim Prince 2005-09-13, 6:59 pm |
| glen herrmannsfeldt wrote:
> Tim Prince wrote:
>
>
>
>
>
>
>
> You mean like C89? How many C99 compilers do you know of?
> About as many as F2003 compilers?
No, like K&R, although C89 supports that style and adds (not fully
mandatory) support for float and long double math library.
>
>
>
>
>
> Well, the default type in C is int in the cases where it
> matters. Otherwise variables have to be declared either double
> or float.
>
In traditional C, there is no option to support float arguments; they
are promoted to double. In the absence of prototype, that promotion
remains a default. Likewise, float expression evaluation was promoted
to double, and there are still compilers which do that in their usual
language standard compliance mode. Certainly, reliance on defaults is
not satisfactory practice, but OP appears to criticize Fortran for
having defaults differing from typical C++ practice.
| |
| glen herrmannsfeldt 2005-09-13, 6:59 pm |
| Tim Prince wrote:
> glen herrmannsfeldt wrote
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> No, like K&R, although C89 supports that style and adds (not fully
> mandatory) support for float and long double math library.
With the math.h header file the arguments will be converted to
double. The sqrtf() man pages I find seem to indicate C99.
I believe they are required in C99, and optional in C89.
To get back on topic, the early (before 1966) Fortran compilers
required function names to end in f, and array names not to end
in f. So Fortran had sqrtf() and sinf().
[color=darkred]
[color=darkred]
> In traditional C, there is no option to support float arguments; they
> are promoted to double. In the absence of prototype, that promotion
> remains a default. Likewise, float expression evaluation was promoted
> to double, and there are still compilers which do that in their usual
> language standard compliance mode. Certainly, reliance on defaults is
> not satisfactory practice, but OP appears to criticize Fortran for
> having defaults differing from typical C++ practice.
Anyway, yes, with C and C++ it is most likely that floating point
expressions and math library functions are done in double precision,
where in Fortran, unless one specifically asks, in single precision.
Though the popular processors do everything in double precision
(or more), anyway.
-- glen
| |
| Jan Vorbrüggen 2005-09-14, 7:57 am |
| > Though the popular processors do everything in double precision
> (or more), anyway.
If you mean x86 by that, I was under the impression that they can
be constrained to actually implement IEEE 754 semantics at the two
lower precisions - certainly when generating SSE2 code, but even
when generating x87 code. Am I wrong?
Jan
| |
| glen herrmannsfeldt 2005-09-14, 7:57 am |
| Jan Vorbrüggen wrote:
[color=darkred]
> If you mean x86 by that, I was under the impression that they can
> be constrained to actually implement IEEE 754 semantics at the two
> lower precisions - certainly when generating SSE2 code, but even
> when generating x87 code. Am I wrong?
There are control register bits that specify the number
of fraction bits to generate for some operations.
To do it right, you would need to change that fairly often,
and I believe it doesn't apply to all operations.
-- glen
| |
| Brooks Moses 2005-09-14, 7:00 pm |
| Ian Chivers wrote:
> I've just run the c++ example below with
> cygwin g++ 3.4.4.
[...]
> this now returns the following output.
>
> -1 -0.0174524063 0.9998476952 -0.01745506479
> 0 0 1 0
> 1 0.0174524063 0.9998476952 0.01745506479
> 29 0.4848096152 0.8746197099 0.5543090439
> 30 0.5000000126 0.8660253965 0.5773502886
> 31 0.5150381048 0.8571672827 0.6008606666
> 44 0.6946583715 0.7193397993 0.9656887777
> 45 0.7071067966 0.7071067657 1.000000044
> 46 0.7193398297 0.6946583401 1.035530401
> 59 0.8571673052 0.5150380674 1.664279515
> 60 0.8660254184 0.4999999748 1.732050924
> 61 0.8746197311 0.484809577 1.804047966
> 89 0.9998476956 0.01745238308 57.29003832
> 90 1 -4.371139e-08 -22877332.43
> 91 0.999847694 -0.01745247049 -57.2897513
>
> I stopped teaching c++ in 2002. when
> did this behaviour come into C++ compilers?
What behavior? If you're talking about the stuff regarding promoting
the float arguments to double and evaluating the result in double
precision: do you have some evidence that -4.37e-08 is _not_ a
double-precision-accurate calculation of the cosine of the
single-precision number closest to pi/4?
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
|
|
|
|
|