ix426@sdcc6.ucsd.EDU (Tom Stockfisch) (01/25/88)
In article <11440@brl-adm.ARPA> lamonts@Sds.Sdsc.EDU (Steve Lamont) writes: >Herman Rubin <cik@l.cc.purdue.EDU> says > >> I find that I can do much better mathematical programming in C than in >> FORTRAN.... The major disadvantages are >> the lack of indirection and casting, and the requirement that a function has >> an argument. > >There are whole bunches more reasons for using FORTRAN for *certain* >applications than just power operators and multi-dimensional arrays. I don't get it. C *has* multi-dimensional arrays. >The >COMPLEX data type, f'rinstance. True. This is the only time I use fortran -- when I need COMPLEX, and I can't use C++. >...(in fact, there are no >INTRINSIC functions, in the FORTRAN sense at all in the C language, at least >as far as I interpret the term.... please feel free to correct me if I am >mistaken...;-) ). That is true, in a formal sense. However, C implementations are allowed to translate standard library calls into in-line code. For example, on the Celerity machine I work on, the entire math library (except for pow()) is microcoded. The C compiler will then convert, e.g., sin(x); into one or two assembler instructions, provided the math library (-lm) is mentioned in the argument list to "cc". >I don't see the lack of indirection as a major disadvantage in the type of >programs FORTRAN is suited to. Perhaps I am missing the point here. Can >someone please illuminate the subject? The lack of pointers in fortran means you cannot do dynamic memory allocation. I've seen many fortran programs that solve a problem whose size is determined by user input define arrays (and worse, matrices) of huge size just in case the user asks for a big problem. When someone runs the program for a small case, it gets swapped out unnecessarily. Then when a very large case is tried (bigger than the arrays were defined for), the whole program has to be recompiled. You also can't have an array of pointers to functions in fortran. This is a quite handy object for creating a convenient to use non-linear simultaneous equation solver. I have written C programs which allow the user to choose interactively a list of functions (representing equations) and list of parameters to adjust to satisfy the equations. Besides array of function pointers, it needs an array of double pointers for the parameters. >In some ways, FORTRAN actually *wins*. For example, named COMMON seems to me >to be a better way of handling external variables than simply hanging them out >in space. The only disadvantage that I seen in COMMON is that names of things >in COMMON can be different between subprogram units, making the code harder >to understand.... ...and making errors hard to find. In C when I add one more variable, I just add it to my extern.h file which is "#include"ed in most other files. In fortran, I have to go into a zillion places and make sure the common blocks are up to date (or is the "include" facility of unix f77 in the ansi standard?). >Yes, FORTRAN does run like a slug on some systems. That alone may militate >against using it over C. But, please, don't malign a very useful and, need I >say, venerable language. >... -- Steve Lamont I try not to get into language wars, but... In C you can write interactive programs in which you input complex commands which are then parsed and executed. In fortran you write programs which just prompt you to input x and y and then follow a fixed regimen. If an interactive editor, like vi, is a must for editing, why aren't interactive numerical programs a must for number crunching? Besides pointers, I often use struct's in scientific programming. To work out the dynamics of a finite lattice of spins that can be, say, up and down, with nearest-neighbor interactions, it is very convenient to define something like struct SPIN { enum STATE { DOWN, UP } state; struct *neighbors[COORDINATION_NO]; } lattice[LATSIZE]; To do this in fortran, you need many parallel arrays, and the resulting code is very hard to understand/debug/explain-to-someone-else. -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu
jto@tolsun.oulu.fi (Jarkko Oikarinen) (01/31/88)
(Just forwarding this message...) In article <3597@sdcc6.ucsd.EDU> (Tom Stockfish) writes: /* Several lines deleted */ >In C you can write interactive programs >in which you input complex commands which are then parsed and >executed. In fortran you write programs which just prompt >you to input x and y and then >follow a fixed regimen. ... Which command(s) FORTRAN is(are) missing that make interactive programs impossibility? For serious number-crunching I think FORTRAN is superior to C. 1) COMPLEX variables: Write complex arcus hyperbolic tangent in C! 2) single precision: all (ALL) real math is performed in double precision in C. This takes time, especially if you have no db floating point support. Transcendental functions require far more (double) multiplications than single versions. This is very advantageous in graphics where no great precision and a lot of computation is required. I agree the limitation of FORTRAN, which were supposed to be corrected on ANSI FORTRAN 8X, but it never appeared(to my knowledge). Jouko Holopainen University of OULU (FINLAND) dept. of electrical engineering -- ======================================== Jarkko Oikarinen ...!tut!oulu!jarkko jarkko@tolsun.oulu.fi ========================================
shirono@grasp.cis.upenn.edu (Roberto Shironoshita) (02/02/88)
In article <257@tolsun.oulu.fi> jto@tolsun.UUCP (Jarkko Oikarinen) writes: > In article <3597@sdcc6.ucsd.EDU> (Tom Stockfish) writes: > >In C you can write interactive programs > >in which you input complex commands which are then parsed and > >executed. In fortran you write programs which just prompt > >you to input x and y and then > >follow a fixed regimen. ... > Which command(s) FORTRAN is(are) missing that make interactive > programs impossibility? Interactive programs are not an impossibility in FORTRAN. It so happens that the "interactive" part of a FORTRAN program is usually sub-optimal or simple. The answer is good _standard_ libraries. That's where C's main power resides (aside from being a very small language). It is the standard libraries that usually do most of the work (unless you don't inted to have your program ported to other types of machines). > For serious number-crunching I think FORTRAN is superior to C. I agree. However, it is still possible to give a (moderately?) complex user interface to such a program, by coding the number-crunching routines in FORTRAN, and the I/O in C. Of course, this implies that it is possible to obtain FORTRAN object code symbols (function names) using the C compiler (like appending an `_' at the end of the C lexeme), or viceversa. I know it is possible to do such a thing under Ultrix (we have a graphics package written in FORTRAN, which interfaces with students' graphics programs written in C). I would hope it is possible to do under System V, but I'm not sure. Roberto Shironoshita ----------------------------------------------------------------------- Disclaimer 1: The opinions expressed here are my own. The University need not share them, or even be aware of them. Disclaimer 2: Like most humans, I'm bound to err at times. I believe what I have said, but agree that I may be wrong. @@@@@@@@@\ Full Name: Roberto Shironoshita @@ @@ Occupation: BSE candidate in Computer Science @@ @@ Organization: University of Pennsylvania @@@@@@@@/ @@ Network Address: @@ PENNnet: shirono@eniac.seas @@@@ Internet: shirono@eniac.seas.upenn.edu
ix426@sdcc6.ucsd.EDU (Tom Stockfisch) (02/03/88)
In article <257@tolsun.oulu.fi> jto@tolsun.UUCP (Jarkko Oikarinen) writes: >(Just forwarding this message...) > >In article <3597@sdcc6.ucsd.EDU> (Tom Stockfisch) (that's ME) writes: >>In C you can write interactive programs >>in which you input complex commands which are then parsed and >>executed. In fortran you write programs which just prompt >>you to input x and y and then follow a fixed regimen. ... >Which command(s) FORTRAN is(are) missing that make interactive >programs impossibility? Data processing is hard in Fortran. Of course, it's not impossible, it's just much more convenient to do it in C. You can't use lex(1) or yacc(1) with fortran (yes, I know you can use ratfor with lex). Have you ever written a symbol table package in fortran (with install() and lookup())? It is very messy without a "struct" facility. Besides which, in fortran you have to hard code the size of the table, since there is no dynamic memory allocation possible. >For serious number-crunching I think FORTRAN is superior to C. > 1) COMPLEX variables: Write complex arcus hyperbolic tangent in C! As I believe I said in my posting, I use fortran for complex arithmetic. 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 or not numerically stable enough. > 2) single precision: all (ALL) real math is performed in double > precision 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. > Transcendental functions require > far more (double) multiplications than single versions. Only if you have an algorithm with slow (e.g. linear) convergence. 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 quadratic convergence, such as newton raphson, it takes only one extra iteration to turn single precision into double. > Jouko Holopainen -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/08/88)
In article <257@tolsun.oulu.fi> jto@tolsun.UUCP (Jarkko Oikarinen) writes: >For serious number-crunching I think FORTRAN is superior to C. > 1) COMPLEX variables: Write complex arcus hyperbolic tangent in C! Certainly, things that are built into the language are more convenient. Complex arithmetic is the only example anyone ever comes up with; by now all of us C numerical programmers have our own complex arithmetic support, which we were able to write effectively in C using its data structuring facilities (in a very simple way -- no linked lists etc.). In over a dozen years of scientific programming in Fortran, however, I seldom (I won't say never) had occasion to use COMPLEX arithmetic. I did, on the other hand, often wish for reasonable support for data structures! Now that I have C available, you won't catch me using Fortran at all (except occasionally in interfacing to existing Fortran-based applications). By the way, complex arithmetic was proposed for ANSI C, but it didn't muster enough support. I think this was mostly because it would be a large new invention, and the main argument for it was that it would make C more palatable to Fortran programmers. I know I dislike that type of argumentation, and perhaps so did others.. There are many other types of number (and other mathematical objects) that neither language supports. At least with C I can implement my own support for them. > 2) single precision: all (ALL) real math is performed in double > precision in C. There were historical reasons for this, but it's fixed in ANSI C.
jto@tolsun.oulu.fi (Jarkko Oikarinen) (02/09/88)
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 ========================================
feg@clyde.ATT.COM (Forrest Gehrke) (02/11/88)
In article <3607@sdcc6.ucsd.EDU>, ix426@sdcc6.ucsd.EDU (Tom Stockfisch) writes: > > As I believe I said in my posting, I use fortran for complex arithmetic. > 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 or not numerically stable enough. > || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu Using a simple struct added to stdio.h so that you can handle the a +j b pair easily, it is no big deal to write the C subroutines that will do the 4 arithmetic functions plus a square root and exponential for complex arithmetic. Numerical stability can be held quite well by keeping all calculations rectilinear, changing to polar form only if the end result in wanted in that form. There is no need to wait for C++ if complex is all you are looking for. I would be glad to email if you would like. Forrest Gehrke
wes@obie.UUCP (Barnacle Wes) (02/23/88)
In article <7217@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > There are many other types of number (and other mathematical objects) > that neither language supports. At least with C I can implement my > own support for them. And with C++, you can even make them look like a *real* (no pun intended) data type, and define the standard operators for them (you know, + - * / < > ==). -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/28/88)
In article <72@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <7217@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >> There are many other types of number (and other mathematical objects) >> that neither language supports. At least with C I can implement my >> own support for them. >And with C++, you can even make them look like a *real* (no pun >intended) data type, and define the standard operators for them (you >know, + - * / < > ==). You're assuming that there is an analog of these operators defined for my "funny numbers", and that there are no other operators of equal of greater importance. Unfortunately this isn't true of all kinds of "funny numbers". Take holors as one example; addition is well-defined, but not multiplication; instead there are several ways to do something analogous to multiplication, which the conventional notation simply cannot support. Or, you might find Boolean algebra operating on bit variables a more familiar example.
mouse@mcgill-vision.UUCP (der Mouse) (03/09/88)
In article <259@tolsun.oulu.fi>, jto@tolsun.oulu.fi (Jarkko Oikarinen) writes: [Apparently this is someone else (Jouko Holopainen?) again] > In aticle 4882 Tom Stockfisch writes: >> In article <4257> Jouko Holopainen writes by courtesy of Jarkko Oikarinen: >> [I use FORTRAN for nothing but complex arithmetic.] As soon as C++ >> becomes widely available, I won't use fortran at all. > Can You write a=b**c/d+e... in C++ with complex operators? Probably not (I don't think you can change the tokenizing rules to make ** a single operator), but you can certainly write a=b^c/d+e. (Though you may need to parenthesize to get ^ to take precedence over /, and it is arguably bad style to have ^ mean XOR for integers and exponentiation for complex.) > If this is the case, how can You redefine division? There is a syntax for it, which I don't know the details of (I don't use C++; I know what it can do but not the details of how it does it). der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu