andyo@masscomp.ccur.com (Andy Oram) (09/14/90)
I would like to suggest that the success of any computer offering depends partly on the quality of documentation and training available. This is a point forgotten by too many engineers. We can't just wait to see if people want something -- we have to tell them what it can do for them and BRING THEM to want it. Perhaps the wrangles over various language features have made a lot of people ambivalent, and hampered their ability to promote Fortran 90 even if they consider it an advance overall. This isn't the proper newsgroup to carry on a debate about social and educational issues (respond to me if you want), but I only know of two large-scale works on Fortran 90, and wonder if anyone is planning any kind of training effort. I am a technical writer planning a book myself, and have found about a dozen people to act as consultants and reviewers. The two existing works are: Metcalf, Michael, and Reid, John, Fortran 90 Explained, Oxford Science Publications, Clarendon Press (division of Oxford University Press), 1987. Probably updated since then. Brainerd, Walter S., Charles H. Goldberg, and Jeanne C. Adams, Programmer's Guide to Fortran 90, Intertext Publications, McGraw-Hill Book Company, New York, 1990. Both are excellently written and conceptually strong textbooks, but I think there's room for something else that's practical, directed toward a scientist or engineer who is very goal-directed and wants to focus on the application.
jlg@lanl.gov (Jim Giles) (09/18/90)
From article <58199@masscomp.ccur.com>, by andyo@masscomp.ccur.com (Andy Oram): > [...] > Brainerd, Walter S., Charles H. Goldberg, and Jeanne C. Adams, > Programmer's Guide to Fortran 90, Intertext Publications, McGraw-Hill > Book Company, New York, 1990. Brainerd, et. al. is very biased in favor of the new standard. The book glosses quickly over the really ugly features of the proposed standard. If they aren't worth being written up in detail - not even by members of the committee, why are they in the proposal (in particular: pointers to array sections - a quick glance reveals ther're redundant with no useful functionality - above book mentions them, but gives no examples of their use). J. Giles
myb100@csc.anu.oz.au (09/18/90)
In article <63197@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <58199@masscomp.ccur.com>, by andyo@masscomp.ccur.com (Andy Oram): >> [...] >> Brainerd, Walter S., Charles H. Goldberg, and Jeanne C. Adams, >> Programmer's Guide to Fortran 90, Intertext Publications, McGraw-Hill >> Book Company, New York, 1990. > > Brainerd, et. al. is very biased in favor of the new standard. The book > glosses quickly over the really ugly features of the proposed standard. > If they aren't worth being written up in detail - not even by members > of the committee, why are they in the proposal (in particular: pointers > to array sections - a quick glance reveals ther're redundant with no > useful functionality - above book mentions them, but gives no examples > of their use). > J. Giles Pardon my ignorance - but what do you mean by 'pointers to array sections' ? Am I wrong in guessing (probably, yes :-) ) that these are the addresses where a particular section (say a row/column, can't remember which) of an array starts ? If this is the case I can suggest something useful for them. (If they're not, I'll just quietly crawl away again :-) ) Thanks =============================================================================== Markus Buchhorn /// | This space Mt Stromlo and Siding Spring Observatories, Canberra /// | PMB Weston Ck. P.O. A.C.T. 2611, Australia \\\/// | intentionally markus@mso.anu.oz.au -or- nssdca::psi%mssso::markus \XX/ | left blank ===============================================================================
maine@elxsi.dfrf.nasa.gov (Richard Maine) (09/19/90)
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]wsb@boise.Eng.Sun.COM (Walt Brainerd) (09/20/90)
In article <63197@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <58199@masscomp.ccur.com>, by andyo@masscomp.ccur.com (Andy Oram): > > [...] > > Brainerd, Walter S., Charles H. Goldberg, and Jeanne C. Adams, > > Programmer's Guide to Fortran 90, Intertext Publications, McGraw-Hill > > Book Company, New York, 1990. > > Brainerd, et. al. is very biased in favor of the new standard. The book True. As the preface says, the book emphasizes the new features of F90. > glosses quickly over the really ugly features of the proposed standard. True. But I sure didn't vote for them ^:) > If they aren't worth being written up in detail - not even by members > of the committee, why are they in the proposal (in particular: pointers > to array sections - a quick glance reveals ther're redundant with no > useful functionality - above book mentions them, but gives no examples > of their use). > > J. Giles This book is _not_ a complete description and reference work for Fortran 90 (that will be available from McGraw-Hill next year, and all the ugly stuff will be covered!), but discusses the main features that would be used by a Fortran 90 programmer writing new code. And the philosophy is to show only one way to do things (hopefully the best way), so naturally the ugly stuff is not discussed. Regarding pointers, the kind J. Giles wants (addresses) were not put in Fortran 90. By a narrow margin, the X3J3 folks preferred "descriptors" or "aliases" as the model. Hence one of these things (call them what you like) can "point to" / "alias" / "reference" a row or a column of an array (or a two-dimensional part or a five-dimensional array, or the next element in a linked list, etc.). Obviously this is useful, even if it is not what J. Giles wants (and we should have some examples in the book of pointers to sections of an array!). -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
jlg@lanl.gov (Jim Giles) (09/20/90)
From article <142733@sun.Eng.Sun.COM>, by wsb@boise.Eng.Sun.COM (Walt Brainerd): > [...] > Regarding pointers, the kind J. Giles wants (addresses) were not > put in Fortran 90. By a narrow margin, the X3J3 folks preferred > "descriptors" or "aliases" as the model. Hence one of these things > (call them what you like) can "point to" / "alias" / "reference" > a row or a column of an array (or a two-dimensional part or > a five-dimensional array, or the next element in a linked list, > etc.). Obviously this is useful, even if it is not what > J. Giles wants (and we should have some examples in the book > of pointers to sections of an array!). Actually, this is what I object to - the casual assertion that "Obviously this is useful." It does not give the user any functionality that he doesn't have with array subscript expressions already. What it does is introduce the spectre of aliasing unnecessarily. The committee tried to allay such fears with the "TARGET" attribute, but any two pointers of the same type are still assumed to be aliased - even if they always point into different arrays. In order to avoid this problem, the user will have to use array subscript expressions directly instead of pointing to the section - but this is what the user would have to do even if the pointer-to-section feature didn't exist. So the feature doesn't add anything new. It just adds a "syntactic sugar" notation that users will have to be taught to avoid. The use of pointers should be limited to simulating recursive data structures and the pointer-to-section idea should be deleted from the standard. Now, if they wanted to reintroduce the "ALIAS/IDENTIFY" feature - which really _does_ add functionality - then there would be reason to consider the proposal more seriously. J. Giles
jlg@lanl.gov (Jim Giles) (09/20/90)
From article <1990Sep18.144822.2854@csc.anu.oz.au>, by myb100@csc.anu.oz.au: > [...] > Pardon my ignorance - but what do you mean by 'pointers to array sections' ? > > Am I wrong in guessing (probably, yes :-) ) that these are the addresses > where a particular section (say a row/column, can't remember which) of an > array starts ? If this is the case I can suggest something useful for them. You are probably lucky not to know what they are and I am somewhat reluctant to explain something to you which you will not really ever want to use. But, here goes anyway. Here is one of the examples given in the June 1990 version of the Fortran 90 proposal: EVERY_OTHER => VECTOR(1:N:2) where both VECTOR is a one-d array with the TARGET attribute, and EVERY_OTHER was declared as a one-d POINTER. After the execution of the above statement, a reference to EVERY_OTHER is exactly the same as if you wrote VECTOR(1:N:2). So, for example: EVERY_OTHER = 0.0 VECTOR(1:N:2) = 0.0 These statements have exactly the same meaning (zero every other element of VECTOR). The so-called POINTER is actually a full descriptor of an array - with extent, rank, and stride attributes. The problem arises in the following manner: EVERY_OTHER_PRIME => OTHER_VECTOR(1:N:2) This statement assigns another pointer similar to the first, but to a different array with the same bounds. So the following now occurs: EVERY_OTHER = EVERY_OTHER_PRIME VECTOR(1:N:2) = OTHER_VECTOR(1:N:2) You might expect these two statements to have the same meaning - and semantically they do. But, the compiler would have to do some quite sophisticated checking to determine whether the two pointers were aliased or not - even so, it might be unable to determine that they aren't (if they are dummy arguments, for example). Even a simple compiler can tell that the second statement contains no aliasing (unless the two vectors are EQUIVALENCED locally). So the compiler is likely to generate _very_ much more efficient code for the second statement. For this reason (and this is a simple example - real cases would be even more likely to cause problems) the user would naturally prefer to use the second notation everywhere. So, why is the pointer-to-section feature in the standard at all? J. Giles