Learning Fortran
in [Matlab]
|
From: Steve Amphlett on 21 May 2010 10:37 Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <eaee413f-f239-4b17-b427-b5bc571eb8f1(a)v37g2000vbv.googlegroups.com>... > On 21 Mai, 15:33, dpb <n...(a)non.net> wrote: > > > I don't believe there's any way one can make such generic claims of > > superiority of either. > > No one have talked about *superiority*. What I have said > is that fortran is *inferior* as it has been obsolete for > the past 40 years. > > Rune Hmm, I can only give a 30-year history myself, but this is the order I learned the mainstream languages (and used them for real work): BASIC Assembler C FORTRAN C++ Matlab comes in between Assembler and C. Learning FORTRAN (out of necessity for using some simulation package) was a real chore. I still use C, C++ daily and FORTRAN for some projects (extending existing FORTRAN codes). I must admit, I've never written a MEX file using either FORTRAN or C++.
From: dpb on 21 May 2010 10:42 Rune Allnor wrote: > On 21 Mai, 15:33, dpb <n...(a)non.net> wrote: > >> I don't believe there's any way one can make such generic claims of >> superiority of either. > > No one have talked about *superiority*. What I have said > is that fortran is *inferior* as it has been obsolete for > the past 40 years. But for that to be so means you can only talk about 40-yr old FORTRAN and that is _NOT_ Fortran. "Inferior/superior" is, in this instance, in the eye of the beholder methinks... :) --
From: Walter Roberson on 21 May 2010 10:54 Rune Allnor wrote: > On 21 Mai, 15:33, dpb <n...(a)non.net> wrote: > >> I don't believe there's any way one can make such generic claims of >> superiority of either. > > No one have talked about *superiority*. What I have said > is that fortran is *inferior* as it has been obsolete for > the past 40 years. Oh, nonsense! 40 years ago was 1970, just 4 years after the release of FORTRAN66, and before the large language upgrade of Fortran77. C and C++ both have goto. You don't have to use goto in C or C++ if you do not want to, and you do not have to use goto in any fortran from Fortran77 onwards.
From: Jim on 21 May 2010 11:00 Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <73d8e77f-b3ed-41b0-b684-da829e485ff5(a)c7g2000vbc.googlegroups.com>... > Compare it to a only sligthly younger language, C++, itself > somewhere around 30 years old based on C, which is another > 10 years older. C++ allows the programmer to not change the > *language*, which is standardized, but by adding *libraries*. > The skilled C++ programmers are able to essentially develop > their own, application-specific, languages, that easily run > way faster than anything fortran has to offer. > > The present trend in programming is to write human-understandable > code. Only amateurs and fools think that source code is written > once, never to be seen by human eyes again. The fact of life > is that source code that was never intended as anything but > a one-off is copied, amended, changed, and even evolves into > huge systems. I can't find the references off the top of my > head, but I have seen some claims that both the C programming > language and the UNIX operating system started out the same > was as MS-DOS and later windows; as quick'n dirty ad hoc hacks > intended to just get something going. Just a little interjection to disambiguate few things: - FORTRAN was created in the 1950s, and along with Ada is considered one of the initial programming languages. Earliest date on can find on a FORTRAN compiler is 1955, but since lack of clear and consistent documentation hasn't changed since the dawn of computing, that's probably an estimate. - The C compiler was created by Brian Kernighan during the UNIX development project, in order to help him, Dennis Ritche, Weinberger and a host of others on their team more rapidly develop the OS itself. C's official birth year is marked as 1972, while the first official UNIX release has a date of 1974. - C++ was created in the early 1980s and was initially just a pre-processor that would translate all of the code into C code using macros and pragmas, etc. There are various folks who argue the official birthdate of C++ due to this (since later there was a specific C++ compiler that wasn't just a pre-processor), wading into that pool seems pointless to me personally, but feel free to investigate it further if it floats your boat. The primary complaint about the pre-procedural languages (starting with first Pascal and then C) are their lack of adequate scoping rules. With procedural (or functional) languages, one gained the ability to limit the scope of variables and was able to create a subroutine which could be called and then reliably return to the point of origin. The problem with goto and label is not only could one jump around to any particular point, but you could come *from* any particular point. The "return" effectively solved this problem. Moreover, the fact that every variable in early languages was global (FORTAN, Ada, COBOL, etc.) meant that it was extremely easy to screw up one's own logic, or someone else's by accident. Local variables resolved this problem as well. To my knowledge the only "language" which actually fully supported (and even encouraged) altering the language itself remains Lisp, and its offspring. The things one can do with the lamba construct would probably make most programmers dizzy. If that's useful, you're welcome. Otherwise, I'd rather not wade any further or deeper into some sort of religious language war. Have a good day! Jim
From: Baalzamon on 25 May 2010 06:50
Howdy there, once again. With regards to a few of the points brought up by various people. 1) The main code has several subroutine calls and by my quick flowchart-check the calls go five deep at a max. That is to say once calls another, which calls another, which calls another etc. 2) There are goto jumps, including the much tricksome (for a complete newcomer such as myself) 'computed?' goto. 3) The maths behind the routine are currently beyond me. Though largely this wouldn't be a problem if the source code was filled with comments explaining what is the point of lines x to y etc. Er there were some more points, however, I got lost during the reading of this topic. Currently I have translated some of it...until i found that I had to set x=y where y is not established until a subroutine call later on. Some specfic questions: excerpt from code if (a .eq. 1) goto 85 Now does this mean that if a does not equal 1 then execute code immeadiately after the if statement...then when we arrive at '85' do we ignore it or execture also? Go to (15,25), L DOes this mean depending upon the values of 'L' jump to 15 or 25? If so Is the argument governed by 'L' in ascending order? Such that, say 'L' could be 1 or 2 then if L=1 go to 15 and if L=2 go to 25? |