Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: Education for Fortran 90 Message-ID: Date: 18 Sep 90 21:16:40 GMT References: <58199@masscomp.ccur.com> <63197@lanl.gov> <1990Sep18.144822.2854@csc.anu.oz.au> Sender: news@skipper.dfrf.nasa.gov Organization: NASA Dryden, Edwards, Cal. Lines: 73 In-reply-to: myb100@csc.anu.oz.au's message of 18 Sep 90 04:48:21 GMT On 18 Sep 90 04:48:21 GMT, myb100@csc.anu.oz.au (Markus Buchhorn) said: Markus> In article <63197@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: Jim> Brainerd, et. al. is very biased in favor of the new standard. The book Jim> ... Well of course it is. What do you expect? Regardless of the question of whether Jim's or my biases agree with Brainerd's (not too hard to figure out), the point of the book is to show how programmers can use Fortran 90. As far as I'm aware, it's not supposed to be a book about what should or should not be in the standard or whether there should be such a standard at all. I got the impression that it was a book about how to program in the standard as it now exists (in draft form anyway). I'm not sure that "bias" is quite the right term to apply. Any book about how to use a language tends to have the implicit bias that the language must be worth using or the book wouldn't exist. Off hand, I don't recall any books that present a thesis like "language X is a crummy language, but if you insist on using it anyway, here is how." Markus> Pardon my ignorance - but what do you mean by 'pointers to Markus> array sections' ? Markus> Am I wrong in guessing (probably, yes :-) ) that these are the Markus> addresses where a particular section (say a row/column, can't Markus> remember which) of an array starts ? If this is the case I can Markus> suggest something useful for them. You are close. But pointers in Fortran 90 are not just addresses. They are "dope vectors", meaning that they also contain information about the array dimensions. The pros and cons of this have been debated earlier. For instance, if the array A and the pointer P are declared as real, target :: a(100,100) real, pointer :: p(:,:) then you might at some point assign p with the statement p => a(10:20:5,20:30:2) which makes P point to the 3 by 6 array section of A consisting of columns 10,15,20 and rows 20,22,24,26,28,30. Then you can refer to, for instance p(2,2) (meaning a(15,22)). You can also pass P to a subroutine and the "dope vector" actually passed includes not just a simple address, but also the information that P is a 3 by 6 array and what the spacing is between the rows and columns of P. In the closest Fortran 77 equivalents, you would have to pass all this information as extra arguments; in Fortran 90, the supplemental information is automatically passed with the array (or pointer). For a simpler (and more commonly useful) case, the pointer real, pointer :: q(:) can be assigned with q => a(50,:) to point to the 50'th row of A. Now q can be treated as a vector, even though the elements are not contiguous; the compiler and runtimes keep track of the needed details. I'll not try to discuss the question Jim raised of whether there are other equally good ways of achieving the same ends. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]