Learning Fortran
in [Matlab]
|
From: Baalzamon on 25 May 2010 10:40 (sorry if this is a double post, I hit the wrong button) Much thanks everybody for the helpful advice and comments. I shall investigate the fortran specfic site for further help. Last couple of questions. considering this loop, DO 10 I=1, N a(I)=b(I)/5 10 z(I)=a(I)**2 Is the statement at the end label a part of the loop, I much thought it is.... As for the y=x scenario, it seems that the structure of the fall throughs were confusing me. Once agan thanks folks.
From: James Tursa on 25 May 2010 10:56 "Baalzamon " <baalzamon_moridin(a)yahoo.com> wrote in message <htgngo$3ig$1(a)fred.mathworks.com>... > > DO 10 I=1, N > a(I)=b(I)/5 > 10 z(I)=a(I)**2 > Is the statement at the end label a part of the loop, I much thought it is.... Yes. The above is the same as: a(1:N) = b(1:N) ./ 5; z(1:N) = a(1:N) .^ 2; James Tursa
From: Walter Roberson on 25 May 2010 11:39 Steve Amphlett wrote: > Walter Roberson <roberson(a)hushmail.com> wrote in message > <eZQKn.10565$%u7.5758(a)newsfe14.iad>... >> >> Computed GOTOs were discouraged in Fortran starting with Fortran77. >> None the less, in most languages that support some sort of switch >> statement, the switch cases must be constants, and in the case where >> the values are sequential, the program will end up internally >> executing something like a computed GOTO. The _functionality_ of >> computed GOTOs is thus still very much alive, but the _syntax_ of >> computed GOTOs is not. > Computed GOTO is horrible. I once did something similar in assembler > (my code modified the jump address on the fly, so the program changed > its own flow). Unfortunately the program that puts my meals on the > table is still based on one large computed GOTO. "Jump tables" are still often used in generated code, as they offer fixed-time processing of switch/case statements when the choices are fixed and not too numerous. Pseudo-codely: switch (event_type) { case BUTTON_DOWN: body1; case MOUSE_MOVEMENT: body2; case WINDOW_CLOSE: body3; case HALT_AND_CATCH_FIRE: body4; } might become something like Jump_Table19[] = {&Label19_1, &Label19_2, &Label19_end, &Label19_3, &Label19_4}; Load D8, event_type Subtract D8, =BUTTON_DOWN BranchIfLessThan0, Label19_end LoadEffectiveAddress.Long A7, Jump_Table19[D8] BranchRegister A7 Label19_1: body1; Branch Label19_end Label19_2: body2; Branch Label19_end Label19_3: body4; Branch Label19_end Label19_4: body3; Label19_end: No_Operation Equivalent Fortran code: GOTO (191, 192, 195, 193, 194), eventtype 191 body1 GOTO 195 192 body2 GOTO 195 193 body4 GOTO 195 194 body3 195 CONTINUE No functional difference in the assembly or machine code: the main difference is that switch is easier for humans to read and code.
From: Rune Allnor on 25 May 2010 12:44 On 25 Mai, 17:39, Walter Roberson <rober...(a)hushmail.com> wrote: > No functional difference in the assembly or machine code: the main > difference is that switch is easier for humans to read and code. And that in itself is the reason why *humans* should stick with *human-readable* code. Rune
From: Walter Roberson on 25 May 2010 13:22
Rune Allnor wrote: > On 25 Mai, 17:39, Walter Roberson <rober...(a)hushmail.com> wrote: > >> No functional difference in the assembly or machine code: the main >> difference is that switch is easier for humans to read and code. > > And that in itself is the reason why *humans* should stick with > *human-readable* code. Previously you wrote, "I have never heard of it before, and there is no reason why you should have to deal with it. This was obsolete 40 years ago." It was _not_ obsolete 40 years ago: it is in active use internally in any high performance language, and every serious programmer should know the concept and know how and when to employ it. Human readable code is not the only criteria in programming: circumstances can make performance more important than the ability of the average reader to make sense of the code. Equivalent programming is often used in state machines -- which are often used for "transaction programming" and are often used for programming graphic user interfaces. What any particular person finds easy to read depends on the person's experience; for example, LISP programmers swear by LISP, finding it "easy to read" when others just see a lot of ))))) . Or was LISP too "obsolete 40 years ago" ? Speaking of 40 years ago: as I pointed out to you the other day, 40 years ago was 1970, just four years after the release of FORTRAN66 and 7 years before the release of Fortran77. 1970 was also 2 years before the release of C, and 2 years before the first edition of The PASCAL User Manual And Report, with the first mass market edition (the one everyone knows) of the UMAR not until 1978. If I have tracked properly, 40 years ago was also the first available mostly-complete implementation of Algol68 (people didn't know how to implement some of the features of Algol for about 5 years after they started being discussed.) You like to throw around "obsolete for 40 years", but you have not demonstrated a good grasp of the state of programming 40 years ago. State-of-the-art programming 40 years ago was COBOL66, which (if memory serves me correctly) did not even allow nested structures, and which relied heavily on MODIFY statements to alter the meaning of code! |