Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!quintus!sun!pitstop!sundc!seismo!uunet!mcvax!enea!tut!tolsun!jto
From: jto@tolsun.oulu.fi (Jarkko Oikarinen)
Newsgroups: comp.lang.c
Subject: Re: Why I use C instead of fortran
Summary: C vs. Fortran
Message-ID: <259@tolsun.oulu.fi>
Date: 9 Feb 88 13:40:04 GMT
References: <11440@brl-adm.ARPA> <3597@sdcc6.ucsd.EDU> <257@tolsun.oulu.fi> <3607@sdcc6.ucsd.EDU>
Reply-To: jto@tolsun.UUCP (Jarkko Oikarinen)
Organization: University of Oulu, Finland
Lines: 94

In aticle 4882 Tom Stockfisch writes:
>In article <4257> Jarkko Oikarinen writes:
Well, not Jarkko Oikarinen, but Jouko Holopainen... I was only forwarding...

[Just forwarding messages again...]

>>(just forwading this message...) (that's for Jouko Holopainen = ME)
>>
>>In article <3597> (Tom Stockfisch) writes:
Refer to above-mentioned articles. I cut quite a lot, and may change meaning
of something T.S. said, which is not my intention.

I agree, that data processing is difficult (if not impossible) in fortran. 
The biggest problems with 77 are:
Lack of structs. Of course this can be overcome, but not neatly.
Lack of dynamic memory. This is very serious, and makes programming hard,
where dynamic memory is required.

>As I believe I said in my posting, I use fortran for complex arithmetic
You did.
>I still write main() and all i/o stuff in C, and use fortran
>subroutines only where the complex arithmetic occurs. As soon as
>C++ becomes widely available, I won't use fortran at all. The former's
>complex number facility is far superior to fortran. For example,
>I can redefine complex division if I think the one provided is too
>slow of not numerically stable enough.
Can You write a=b**c/d+e... in C++ with complex operators? If this is the
case, how can You redefine division? Clearly, in any language You can add
a subroutine to do anything you want.
>> 2) single precision: all (ALL) real math is performed in double
>>    recision in C.
>All C compilers I have worked with have an option to disable 
>automatic float-double conversion and allow single precision arithmetic.
>This common extension is even blessed (required?) in proposed ANSI C.
That I didn't know. It is clearly convenient, as I shall show, that required
trigonometric functions are performed in single too. If this is the case 
it is not mentioned by Tom Stockfisch.

>>Transcendental functions require
>>far more (double) multiplications then single versions.
>Only if you have an algorithm with slow (e.g. linear) convergence.
= ln(x) = 1-x+x*x/2 + x*x*x/3 - ...
>If you are summing a series, and c[i] is something like (1/i!), then
>there might be very little difference in the number of terms required
>for single vs. double precision. Especially if you have performed an 
>argument reduction step so that x is between, say, 0 and 0.5
>If you have an algorithm with quatratic convergence, such as newton
>raphson, it takes only one extra iteration to turn single precision
>into double

>> Jouko Holopainen (=Me)

> Tom Stockfisch

Newton-Raphson sounds good, let's have an example:
 f(x)=sin(x)-x  ; appr. for sin(x)

 X(n+1)=X(n)-f(x)/f'(x)=X(n)-(sin(x)-x)/(cos(x)-1)

Clearly N-R is good only for appr. zeros of a function, not the function itself
  A few examples for the convenience of single vs. double functions

Hart J.F. et. al. : Computer Approximations (1968)
gives for natural logarithm approximation:
 ln(x)=z*P(z*z)/Q(z*z) , where z= (x-1)/(x+1)

   single (IEEE 24bit accuracy) double 53bit accuracy

   single: P degree 1, Q degree 1 range [0.71,1.41] 2 mul 2 div
   double:  -"-     2    -"-    3     -"-           5 mul 2 div

or arctan(x), the worst case, there's no algorithm with (1/i!) convergence

  arctan(x) = x*P(x*x), range [0,0.26]

  single : P degree 3 => 4 mul
  double :  -"-     8 => 9 mul more than twice

    range [0,0.37]
  single : P degree 4 => 5 mul
  double :   -"-   10 => 11 mul
Again more than twice the work. Above is optimal algorithm using polynomial
approximation, according to Hart et. al.

Jouko Holopainen Univ. of Oulu (Finland)
                 dept. of El. Eng.

Opinions are mine, not those of Jarkko Oikarinen.

========================================
Jarkko Oikarinen        ...!tut!oulu!jto
                      jto@tolsun.oulu.fi
                   EARN: toljto at finou
========================================