From owner-sc22wg5@dkuug.dk Fri Jan 3 17:21:26 2003 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id RAA42198 for sc22wg5-domo; Fri, 3 Jan 2003 17:21:26 +0100 (CET) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA42193 for ; Fri, 3 Jan 2003 17:21:24 +0100 (CET) (envelope-from michael.metcalf@t-online.de) Received: from fwd08.sul.t-online.de by mailout08.sul.t-online.com with smtp id 18UUZZ-0006iq-00; Fri, 03 Jan 2003 17:21:25 +0100 Received: from metcalf (520066357016-0001@[217.230.188.188]) by fwd08.sul.t-online.com with smtp id 18UUZT-0OWeSOC; Fri, 3 Jan 2003 17:21:19 +0100 Message-ID: <01d801c2b344$69f1d680$6119fea9@metcalf> Reply-To: "Michael Metcalf" From: michael.metcalf@t-online.de (Michael Metcalf) To: , Subject: Fw: FYI: Germany's negative vote on F2000 Date: Fri, 3 Jan 2003 17:23:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Sender: 520066357016-0001@t-dialin.net Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Dear Friends, I'm back after a 10-days' absence (so, first, a Happy New Year to one and all!) and am astonished to find that my original posting of Wolfgang's comments has generated a heated debate with nearly 100 contributions on comp.lang.fortran, far too many to forward. One of the most considered from a non-member of J3/WG5 (Dick H. and Richard M. have weighed in with very sensible replies) is, however, attached. I think it might be useful for those who don't normally see c.l.f. to take a look at this exchange, for instance by accessing the newsgroup at www.google.com. Best Wishes, Mike Metcalf ----- Original Message ----- From: "Norm Clerman" Newsgroups: comp.lang.fortran Sent: 24 December 2002 01:28 Subject: Re: FYI: German's negative vote on F2000 > I'd like to add to this discussion my point of view, which, as I'll > explain, is very much that of a production user: > > My education is as an engineer, but I currently am employed as a > programmer for an optical design firm, and in that, and in previous > positions, work as a programmer, not a scientist or engineer. I wrote my > first FORTRAN program 35 years ago, and for the most part that's what > I've been doing ever since. I also know c, VB and Pascal (via Delphi), > and that's pretty much it. Except for one undergraduate course in > numerical methods I've never taken a computer science course in my life. > > Given this, let me first comment on the statement by our friends from > Germany that the standardization commitee is disconnected from the user > community. I can't speak for the entire community, who can? but I don't > feel at all cut off from it. My lack of a computer science background > disqualifies me, I feel, from volunteering to work on the committee; > more importantly, I don't have the time. I also don't have the time to > read through the draft standard (although I've eagerly read through the > summaries). I'm an end user. I've never read a Fortran standard in my > life; I've always relied on good books and manuals to answer my > questions. If I may paraphrase the movie: "If you build the standard, I > will code." > > I maintain a fairly large, about 100K line, program used to design > lenses. It's been in exsistence since 1969. As late as about 1996 it > still existed as a strictly FORTRAN 77 program. At that time the first > really usable Fortran 90 compilers for Windows NT were available, and we > took a serious look whether to use it, to switch to C/C++, or to > continue with FORTRAN 77. Even though there was a strong bias on our > staff towards Fortran, we tried to be objective, and in the end decided > to move to Fortran 95. There were several reasons: All evidence seemed > to confirm that Fortran still generated the fastest running code; > Fortran 95 seemed the best way to quickly modernize our code given our > exising experience and we felt the Fortran 77 code was getting out of > hand with all the common blocks. Most important, as our friends from > Germany state, Fortran 95 seemed to be the best way to parallelize our > code. We saw the capabilities of pure and elemental routines that > guarantee thread-safe code, coupled with forall and where constructs, > and the OpenMP and MPI standards, and it seemed the logical choice. The > only real argument for C++ over Fortran 95 at the time seemed to be the > existence of more compilers and more tools to interact with the > operating system, mainly to build a nice user interface. > > We, two very experienced Fortran programmers, have spent the past five > years converting our program from FORTRAN 77 to Fortran 95 of which the > last two and a half years were spent rewritting the code for > parallelization. It's been interesting and educational. We've gotten to > the point where the time-consuming section of our program during > execution, the computation of a "merit function" of a lens, can be > summed up by the following snippet of code > > do i = 1, NoOfZoomPositions > Phi(i) = calcMeritFunction (ZoomPosition(i)) > end do > TotalPhi = sum (Phi(1: NoOfZoomPositions)) > > where the element ZoomPosition is a derived type (TZoomPosition) that > describes a particular configuration of a lens and calcMeritFunction > represents tens of thousands of lines of code in dozens of thread-safe > pure and elemental procedures mainly involved with tracing hundreds of > thousand of light rays through the lens using repeated applications of > Snell's law. The element ZoomPosition is just one level of a very > complex hierarchy of types. Briefly: a type (TLens) describes a lens; > it's main component is an array of type (TZoomPosition); each type > TZoomPosition has a many components, the basic one contains the core > optical data called type (TCoreZoom); TCoreZoom in turn contains, among > many other components, an array of type (TElement) which are the lens > surfaces. This continues for several more levals of nesting. It looks > complex, but we feel it very accurately describes the lens. Obviously > this is very object-oriented. We achieved the object-orientation using > several techniques that have been described in this newsgroup, in > Fortran Forum and in other useful sites on the internet over the past > several years, and we've come up with a few of our own techniques. When > I showed the above snippet of code to several persons at the recent > supercomputing conference in Baltimore I kept hearing the phrase that > our program is "embarrasingly parallel." Well, we're not at all > embarrased, the opposite. We're in the final stages of our project and > during the next year we hope to really get up and running in parallel. > As one astute person at the conference guessed, we have a potential to > easily parallelize the above code at a higher level, as part of an > optimization matrix formation, and also at a lower level, by dividing up > the raytracing tasks among the threads (using OpenMP) or among processes > (using MPI). Indeed, because of our redesign we may be able to ship out > different lens configurations to different workstations with MPI and > then divide up the raytracing at the workstation level among as its > processors using OpenMP. > > (I should add that we succeeded in breaking five of the Windows > compilers during development. At least as far as using modules, renaming > variables and overloading procedure names, we feel no compiler > manufacturer could find a better program with which to test than ours. > Indeed, it took one compiler manufacturer, who was very helpful and was > willing to work with us on a weekly basis, five years get to the point > where the compiler would successfully compile our program.) > > Now, to finally get to the main point: WE WANT Fortran 2000, AND WE > WANTED IT THREE YEARS AGO! Not only that, the one key, absolutely > essential feature that we need is the object orientation. Without > exageration the most time-consuming part of our development was mimicing > the object-orientation we could have easily achieved had Fortran 2000 > been available. For example, at all levels of the above-described type > hierarchy we often needed to inquire as to the radius of curvature of a > particular surface. That piece of data is buried at the bottom (or is it > the top in OO parlance?) of the data and because we protect our derived > type components except in the most time-critical routines we had to > write hundreds, if not thousands, of small data inquiry and set > procedures. Again without any exageration, we feel we would have cut our > development time significantly and saved two man-years of work had we > had the OOF capabilities of Fortran 2000. > > Gentlemen, I'm a real expert, I use the language, I want Fortran 2000. > It is not a disaster. For me it will be a blessing. It will save me an > incredible amount of work. It addresses my primary interests: high > performance NUMERICAL AND SCIENTIFIC COMPUTING. It is not too difficult > to learn, certainly not if you start with Fortran 95. Fortran 2000 will > be great. > > I'm sure I've tried most reader's patience. I'd just like to finish with > some remarks about the particular Fortran 2000 features discussed. > First, as an end user I'm free to pick and choose. I've never used > namelist in 35 years; I just never saw the need, but I might with > derived types. Looks to me as if it might be useful. I've had some brief > correspondence with Van Snyder about the specification/definition > separation, and indeed the implementation seems a bit cumbersome in the > new standard. But if I feel I really need it, and I think I will, I'll > learn it. The same goes for exception handling. I definitely need that > so I'll learn it and use it. I'd hardly consider moving to C++ just > because it's not quite as elegant in Fortran 2000 (and maybe it'll be > faster). And certainly you're not going reject the new standard just > because of some stupid square brackets are you? That's absurd. I love > using /= and >= and <+ for the old FORTRAN symbols .NE., etc.; it reads > better. Because of the intelligent decision to maintain backward > compatability, you can use whatever your want. > > Happy holidays to all > > Yours truly, > > Norman S. Clerman > Computer Scientist > Opcon Associates, Inc. > www.opconassociates.com > norm.opcon@fuse.net > > Michael Metcalf wrote: > > As most of you know, the Committee Draft of the next Fortran standard is out > > for balloting. So far the UK has voted 'yes with comments', but now Germany > > has registered a negative broadside that might interest readers of this > > newsgroup. > > > > Regards, > > > > Mike Metcalf > > >