Fortran 77 Manual for beginners
in [Fortran]
|
Prev: proble in common
Next: GNU f90 read() run time error
From: m_b_metcalf on 7 May 2010 01:25 On May 7, 12:29 am, Allamarein <matteo.diplom...(a)gmail.com> wrote: >Where can I download relative documentation? A place to start is http://en.wikipedia.org/wiki/Fortran_language_features but you'll need more later. Regards, Mike Metcalf
From: A Watcher on 7 May 2010 13:55 jfh wrote: > On May 7, 8:46 am, Allamarein <matteo.diplom...(a)gmail.com> wrote: >> I'm a newbie in Fortran 77. It's possible to find a manual with built- >> in statements and that show this language, without digressing too >> much? > > The best book I know on that is "Effective Fortran 77" by Michael > Metcalf, Oxford 1990, but it has long been out of print because that > Fortran dialect has been out of date for 20 years, so you may well > find it only in libraries and on the shelves of oldies. But why is a > newbie doing f77 anyway instead of f95 or f2003? > > -- John Harper F77 is pretty easy to understand and learn if you have any kind of math aptitude. The advanced features and syntax of f90 and up obscure the language, in my opinion. I think it would be wise to learn the basics before going on to the esoteric stuff, especially if you don't already know some other programming languages. I've been writing fortran code since 1968.
From: Richard Maine on 7 May 2010 17:20 A Watcher <stocksami(a)earthlink.net> wrote: > F77 is pretty easy to understand and learn if you have any kind of math > aptitude. The advanced features and syntax of f90 and up obscure the > language, in my opinion. I think it would be wise to learn the basics > before going on to the esoteric stuff, especially if you don't already > know some other programming languages. I have the opposite opinion. F90 need not be esoteric. Several of its features make life a lot simpler. Start with things such as not having to worry about counting columns; I don't know how many people have been confused and asked here about problems relating to fixed source form, but it is a lot. If you are already an f77 programmer, there is *NOTHING* that you absolutely have to learn new in order to use f90. You are also already an f90 programmer. You can learn new features as they become useful to you. Some of them become useful pretty much right away. Others you might never have to learn. Conversely, some f77 features you never have to learn. COMMON is actually quite messy if you really learn all the details of it (not to speak of being very error prone). I'd recommend that new users not bother with even learning COMMON until they have to deal with legacy programs that use it. If you think COMMON is simple (as I see many people claim), that's almost certainly because you are talking about only the particular way you use it instead of about the actual rules (and the odd behavior you get from trivial typos - putting a comma in column 73 is one of my "favorites" in terms of making a mess of COMMON). If you handicap yourself by sticking to f77, then it is all but guaranteed that you will soon be back asking about how to do something that turns out to be one of the new features of f90. It happens quite regularly. Someone insists that f77 does everything they need. Then the next week they are asking how one does, for example, dynamic allocation, or any of a host of other things. > I've been writing fortran code since 1968. Same here; exactly the same year. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 7 May 2010 18:11 Richard Maine <nospam(a)see.signature> wrote: > A Watcher <stocksami(a)earthlink.net> wrote: >> F77 is pretty easy to understand and learn if you have any kind of math >> aptitude. The advanced features and syntax of f90 and up obscure the >> language, in my opinion. I think it would be wise to learn the basics >> before going on to the esoteric stuff, especially if you don't already >> know some other programming languages. > I have the opposite opinion. F90 need not be esoteric. Several of its > features make life a lot simpler. Start with things such as not having > to worry about counting columns; I don't know how many people have been > confused and asked here about problems relating to fixed source form, > but it is a lot. If you are already an f77 programmer, there is > *NOTHING* that you absolutely have to learn new in order to use f90. You > are also already an f90 programmer. But the rules aren't that hard to learn. I do agree that it was much easier getting things into 72 columns on punched cards than it is on a screen, though. By the time you get all the rules for free form continuation down, though, I think it is harder to learn than the rules for fixed form. Actually following the rules is a separate question. Well, first you need to learn an editor to get programs into your computer. If that is WORD or NOTEPAD, then it is likely especially hard to get the columns right. Current vim gives you the row and column at the bottom of the screen. > You can learn new features as they become useful to you. Some of them > become useful pretty much right away. Others you might never have to > learn. Conversely, some f77 features you never have to learn. COMMON is > actually quite messy if you really learn all the details of it (not to > speak of being very error prone). I'd recommend that new users not > bother with even learning COMMON until they have to deal with legacy > programs that use it. If you think COMMON is simple (as I see many > people claim), that's almost certainly because you are talking about > only the particular way you use it instead of about the actual rules > (and the odd behavior you get from trivial typos - putting a comma in > column 73 is one of my "favorites" in terms of making a mess of COMMON). I probably agree with this. But I believe in terms of the previous post, for simple problems often you don't need much of the added complication of F90 and later. I believe the suggestion was for one learning as a first programming language. How do you know which features to learn first and which later? Now, if you have a class that goes through features in an appropriate order, such that you learn the easier to use ones first, then maybe it isn't a problem. But if you pick up a Fortran 2003 reference manual and start reading, you will get confused faster than from a Fortran 77 reference manual. > If you handicap yourself by sticking to f77, then it is all but > guaranteed that you will soon be back asking about how to do something > that turns out to be one of the new features of f90. It happens quite > regularly. Someone insists that f77 does everything they need. Then the > next week they are asking how one does, for example, dynamic allocation, > or any of a host of other things. If one is just starting, usually with smaller programs, there are many things to learn before you get to many of those features. But yes there are some things missing in F77 that are not easy to get around, as you say dynamic allocation likely one of them. >> I've been writing fortran code since 1968. > Same here; exactly the same year. May or June 1972 for me. The IBM S/360 Fortran Reference manual was my 8th grade graduation present, just before going on a month long vacation by car. I did read some of it along the way, but not as much as I had thought I would. It was the rest of the summer when I could actually try running programs and see the results. -- glen
From: Richard Maine on 7 May 2010 18:37
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > > F90 need not be esoteric. Several of its > > features make life a lot simpler. Start with things such as not having > > to worry about counting columns; I don't know how many people have been > > confused and asked here about problems relating to fixed source form, > > but it is a lot. > > But the rules aren't that hard to learn. > much easier getting things into 72 columns on punched cards than > it is on a screen, though. By the time you get all the rules for > free form continuation down, though, I think it is harder to learn > than the rules for fixed form. Actually following the rules is a > separate question. I disagree that it is a separate question. When introducing a new programmer to the language, if he gets it wrong, then he gets it wrong and it really doesn't matter whether he didn't know the rules or accidentally failed to follow them. I'm an engineer. Part of that is caring about getting the results right instead of about being able to say that there was some excuse for why they were wrong. I also disagree that the rules for fixed source form are simpler. Don't forget that blank insignificance comes with fixed source form, for one. And as far as continuation rules, even experts here regularly quote the fixed source ones incorrectly (it is quite common for people to forget that 0 is a special character). When there are trailing blanks on a continued line, you won't even find the experts (or compilers) always agreeing on the exact interpretation. It gets off into subtle points relating to the representation of source code. But continuation rules in free source form are in the category of things you don't need to learn at first. Don't worry about them until you need them. And even once you need them, just learn the simple case (non-character context), as that is all you will likely need for a *LONG* time. With free source form, you can just start writing your first codes without even paying attention to source form questions other than the question about how to tell the compiler you are using free source form. WIth fixed source form, you can't do that. You *HAVE* to learn at least a few of the rules about getting things in the right columns. You can't write even the most trivial of programs without tripping over that... and trip over it is what an awful lot of people do. Furthermore, fixed source form makes for bugs that are very hard to see and diagnose. Reference my prior comment about having a comma in column 73. Add in the blank insignificance that comes with fixed source form. Also add in the implicit typing that you are stuck with in f77 (recall that the question was about sticking with f77; you can half fake implicit none in f77, but you can't do it right). This makes for bugs that often are quite hard to find. I predict mention of various tools (such as the old-style reference maps) that could in theory help find such bugs. But I'll dismiss that along with the mention of how much easier fixed source form was on punched cards. I'm much more interested in what actually happens to people today. One of the things that actually happens with fair regularity is that people using fixed source form get bitten by such things. I know this because they regularly post the questions here. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |