bean@putter.wpd.sgi.com (Bean Anderson) (04/25/91)
Could someone post a note about the current state of the standard? Thanks, Bean
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (04/25/91)
In article <1991Apr24.202115.16119@dragon.wpd.sgi.com> bean@putter.wpd.sgi.com (Bean Anderson) writes:
Could someone post a note about the
current state of the standard?
I was not at the last meeting; but Gary Campbell was there
representing us (sun). Regretfully, this was Gary's last meeting.
Reading over the various published trip reports, the status would
appear to be:
*) The final edits to the ISO standard have been completed.
ISO will probably finish the various procedural matters
between September and October of this year.
*) ANSI might finish before the end of this year.
*) X3.9-1978 (FORTRAN 77) will continue to be a standard in the US
_only_. Unless the rules change, it will not be evolved any
further.
*) I believe that the vote was 26-9 to accept the document as it
stood after the edits. Two copies of the marked up document were
carried to Walt Brainerd (by two different X3J3 members, to
protect against lossage due to a plane crash). Voting against
were the reps from: Microsoft, Convex, Cray, Lahey, Harris, DoD,
Boeing, Unisys and DEC. It should be noted that an organizations rep
votes aye or nay does not necessarily imply that the
organization will or won't build, support, use, or fondle "Fortran90".
The name of the standard appears a bit uncertain. As best I can tell,
the ISO name is "Fortran" while the ANSI name is "Fortran Extended".
Informally, committee folk speak of Fortran 90; but neither ISO nor
ANSI seems to have accepted this bit of folklore.
There is continuing work on a String module, which will probably be
proposed as a collateral standard. One imagines/hopes that a variety
of standardize modules will appear (e.g. all of BLAS1-3, LAPACK and
other things come to mind). There is no reason to believe that such
standards will necessarily come from X3J3; quite the contrary those
closest to various problems should work out the solutions.
X3J3 will have a new chair by next year. WG5 will be discussing what
happens next ("Fortran 2000" who does what, when, how, etc.) at their
next meeting in Lund.
--
----------------------------------------------------------------
Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043prentice@triton.unm.edu (John Prentice) (04/25/91)
In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: > > *) I believe that the vote was 26-9 to accept the document as it > stood after the edits. Two copies of the marked up document were > carried to Walt Brainerd (by two different X3J3 members, to > protect against lossage due to a plane crash). Voting against > were the reps from: Microsoft, Convex, Cray, Lahey, Harris, DoD, > Boeing, Unisys and DEC. > Gee, good to know only the minor players voted against it. So who voted for it? John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (04/25/91)
In article <1991Apr25.043355.26420@ariel.unm.edu> prentice@triton.unm.edu (John Prentice) writes:
Gee, good to know only the minor players voted against it. So who voted
for it?
Everyone else. The formal postmeeting distribution hasn't reached me
yet, so I'd likely misrepresent someone if I relied on inference.
However, in the last go round several "minor" players such as IBM,
Amdahl, Sun, DECUS, and misc. national labs (and several foregin ones)
voted Aye.
--
----------------------------------------------------------------
Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043prentice@triton.unm.edu (John Prentice) (04/25/91)
In article <KHB.91Apr24234512@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: >However, in the last go round several "minor" players such as IBM, >Amdahl, Sun, DECUS, and misc. national labs (and several foregin ones) >voted Aye. If Fortran Extended is not going to be recognized outside the U.S., then why are foreign reps voting on it (or am I confused about what is the U.S. standard versus the international one - ugh) ? Anyone know what the votes of the DOE labs were? Well, I hope this puts all this behind us and we can now get on to building compilers that implement all this stuff. I imagine the people on X3J3 are happy it is over at least. Whatever I may think of FE, I have to admire people willing to spend this kind of time on the standards committee. It strikes me as a rather thankless task. It will be interesting to see if there is ever another standard issued for Fortran however. Given the time it took to get this one and the fast changes occuring in scientific computing (particularly the push to parallelism), I tend to really wonder if Fortran will continue to be used for state of the art code all that much longer. Many of the heavy players in my field are now going to C++ or other languages that express parallelism more naturally. One can (and knowing this newsgroup, probably will) debate the merits of these languages till you are blue in the face, but you got to admit there is alot of pressure to find alternatives to Fortran in scientific computing. Is X3J3 thinking about that at all in contemplating where to go next? If not, what exactly are the priorities? John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
psmith@convex.com (Presley Smith) (04/25/91)
In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: > ... Deleted text ... > > *) I believe that the vote was 26-9 to accept the document as it > stood after the edits. Two copies of the marked up document were > carried to Walt Brainerd (by two different X3J3 members, to > protect against lossage due to a plane crash). Voting against > were the reps from: Microsoft, Convex, Cray, Lahey, Harris, DoD, > Boeing, Unisys and DEC. It should be noted that an organizations rep > votes aye or nay does not necessarily imply that the > organization will or won't build, support, use, or fondle "Fortran90". > I just wanted to thank Kieth for his statement that a nay or aye does not imply that an organization will or will not build a Fortran 90 product. The situation is similar to an election for something like the President of the United States... Even if I didn't vote for the person who is elected, once he/she is the president, I will support that person. I still may not agree with all he/she stands for but he/she is the president. The groups that voted NO on the proposed standard have their reasons for voting NO. - There are concerns that this is not the right standard for the Fortran community. - There are concerns that many parts of the standard have never been implemented and that there will be major flaws found in implementation. (The committee made 93 additional changes at this last meeting...) I could continue this list, but most of it has been said before. The point is that Fortran 90 is going to become the International Standard replacing FORTRAN 77 at the ISO level. In the U.S. there will be two Fortran standards... FORTRAN 77 and this Fortran 90 standard which is currently called Fortran Extended by the X3 community. When X3 determined that FORTRAN 77 would be preserved as a standard in the U.S., the name of Fortran 90 had not been firmly established. Since the precident was set with other standards having the "extended" term added, X3 used that name in it's efforts. It has and remains the intent of X3 for Fortran Extended and the ISO Fortran 90 to be exactly the same document. (There's been debate on this before... I was at the X3 meeting when they X3 to keep FORTRAN 77. It was explicitly stated at that meeting that Fortran Extended would be the ISO Fortran 90 standard.) Bottom line is that Fortran 90 has been approved and will be a new Fortran standard. Those that voted nay will accept that and make their future Fortran plans accordingly. The election is over and the outcome is clear. Thanks Keith for adding the insight to your comments.
chidsey@smoke.brl.mil (Irving Chidsey) (04/25/91)
In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes:
<
<X3J3 will have a new chair by next year. WG5 will be discussing what
<happens next ("Fortran 2000" who does what, when, how, etc.) at their
<next meeting in Lund.
<--
<Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
<SMI 2550 Garcia 12-33 | (415 336 2648)
< Mountain View, CA 94043
What are the relative merrits of smaller, incremental changes every
5-6 years, versus these monstrous rewrights every 12-15 years?
The changes seem to be getting more extensive each time!
Irv
--
I do not have signature authority. I am not authorized to sign anything.
I am not authorized to commit the BRL, the DA, the DOD, or the US Government
to anything, not even by implication. They do not tell me what their policy
is. They may not have one. Irving L. Chidsey <chidsey@brl.mil>mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (04/26/91)
Before I write anything more, I wish to make it clear that I am just trying to satisfy my curiosity. I do not wish in any way to denigrate the efforts nor to question the motives of anyone on X3J3. In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: > *) I believe that the vote was 26-9 to accept the document as it > stood after the edits. Two copies of the marked up document were > carried to Walt Brainerd (by two different X3J3 members, to > protect against lossage due to a plane crash). Voting against > were the reps from: Microsoft, Convex, Cray, Lahey, Harris, DoD, > Boeing, Unisys and DEC. It should be noted that an organizations rep > votes aye or nay does not necessarily imply that the > organization will or won't build, support, use, or fondle "Fortran90". Why would anyone vote against the standard at this late date? Are there outstanding technical problems with the standard which these objectors felt needed to be adressed before the standard is released? Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (04/26/91)
In article <1991Apr25.100524.9831@ariel.unm.edu>, prentice@triton.unm.edu (John Prentice) writes: >In article <KHB.91Apr24234512@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: >>However, in the last go round several "minor" players such as IBM, >>Amdahl, Sun, DECUS, and misc. national labs (and several foregin ones) >>voted Aye. > >If Fortran Extended is not going to be recognized outside the U.S., then >why are foreign reps voting on it (or am I confused about what is the >U.S. standard versus the international one - ugh) ? Anyone know what >the votes of the DOE labs were? Foreign reps are _NOT_ voting on "Fortran Extended", they are voting on the new international Fortran Standard. Since ANSI (read "the USA") have opted to retain the previous Fortran standard in addition to adopting a new one, they have apparently decided to call the new one "Fortran Extended" in order to differentiate. Since ISO/WG5 (read "the rest of the world") is replacing the old Fortran standard with the new one, they have decided to call the new standard Fortran. I feel this makes sense, else they will eventually have to adopt a standard called something like: "the most wonderfully splendiferous and magnificent Fortran" :-) -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+------------------------------------------- #!
bleikamp@convex.com (Richard Bleikamp) (04/26/91)
In article <1991Apr25.235111.26282@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >Before I write anything more, I wish to make it clear that I am just >trying to satisfy my curiosity. I do not wish in any way to denigrate >the efforts nor to question the motives of anyone on X3J3. > >In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM > ... deleted text ... > >Why would anyone vote against the standard at this late date? Are there >outstanding technical problems with the standard which these objectors >felt needed to be adressed before the standard is released? > > Marc R. Roussel > mroussel@alchemy.chem.utoronto.ca I'll try to briefly summarize my feelings on the Fortran Extended draft standard (I was one of the no votes). See the last few paragraphs for a summary of what users can expect in the future from vendors. Technical Concerns 1) The array notation is potentially better looking, and more portable than optimization directives, but will NOT produce better performance from a program. In fact, on vector machines, array notation is very likely to run slower! In essence, this is because many algorithms contain loop carried dependencies which a smart optimizer can deal with and still vectorize, but the array notation equivalent will involve user specified vector temps and multiple array notation assignments. The optimizers in Fortran 90 compilers will need to be even smarter than todays best in order to break even performance wise. Certain array operations, such as vector valued subscripts and passing array sections, will dramatically impact performance on most existing architectures (slower!). Although you only pay the performance penalty when you use the features, they still seem extraneous. Note that some users (as opposed to implementors) disagree with this. 2) Modules are defined in such a way as to mandate an extra compiler pass over the parse tree (or some similar structure). It seems likely that a 386/486 based PC with 4+ megabytes will be the minimum architecture able to compile Fortran Extended programs. If it takes 4-5 years for PC based implementations to show up, this isn't a problem, but if user's were hoping to use Fortran Extended on their 286 boxes they are going to be surprised. The new standard has de-emphasized execution time performance in order to make the programmer's life easier. To do this to Fortran, long known for its good execution speed, seems a little crazy. 3) Parameterized datatypes, although providing a potentially portable way to declare variables with the required attributes, are awkward to use portably. KIND numbers are a compromise that neither encourage portability nor adopt existing practice. Procedural Concerns 1) The interactions between X3J3 and WG5 have not always been optimal. Both groups are responsible for this. If X3J3 had produced a more timely standard, friction between the groups would have been much less. 2) The process X3J3 has followed does not work well. In the future, the committee needs to define the desired functionality, get that reviewed (in a public forum), and then design the language features to implement that functionality. This current committee has spent (wasted?) a lot of time taking out and putting in again many features. The lack of consensus on the desired functionality was responsible for this, and it turn lead to many errors being introduced into the document whenever a feature was added or deleted. 3) Public review comment from the 2nd and 3rd public review was largely ignored. Only real serious errors were addressed. Much of this was undoubtly due to the desire to finish the standard before the next ice age started. Earlier public reviews of the intended functionality would have helped. Philosophical Concerns 1) Parallelism and data partitioning for distributed memory architectures are not really addressed. When Fortran 8x was first started, this was not an issue yet, but it is now. Fortran needs a way to express very coarse grained parallelism. 2) This new language is BIG. Almost as big as Ada. I personally feel that a prototype implementation, like DoD funded for Ada, is necessary to shake out the bugs. There is no mechanism in place at ANSI or ISO to undertake an effort like this. 3) Related to 2), much new functionality has been added. Most of this functionality is available in other forms in existing implementations (not always Fortran). But, the committee has consistently chosen to implement new functionality in a different way than existing practice. This significantly increases the risk of introducing unintended functionality which adds to the implementation cost, or impacts execution time performance, or worst of all, in internally inconsistent, making the feature useless. The committees charter was to standardize existing practice. Some of us feel that the resultant draft is really a new language. 3+)Note that programs which use Cray pointers or VAX records, two commonly available extensions, will have to be substanially modified to use the Fortran Extended equivalents. In general, existing extensions to Fortran 77 do not merge well with Fortran Extended and are unlikely to show up in Fortran Extended compilers (due to technical considerations in the design of the compilers). 4) Companies will need to retrain their programmers to use the new features in Fortran Extended. The changes are so many (many syntactical) that this retraining effort may be similar to that required for Ada. It is unlikely that many companies will spend the money to do this, so programmers will continue to use the Fortran 77 subset. If X3J3 had produced the standard in a more timely manner, with fewer changes, the impact on the users could be spread out over time. 5) Fortran Extended will cost implementors an order of magnitude more $ to implement than Fortran 77. All within 2-3 years. These costs will have to be passed onto the users. If smaller changes had been made in more frequent standards, the cost could be spread out. What's good about Fortran Extended ? 1) Array notation does provide a portable way to express vectorizable and parallelizable operations. Codes will run a bit slower than possible with careful hand tuning (inserting directives), but one code can run on many architectures without any changes (except for datatypes). 2) Structures are long overdue. But VAX structures they aren't. 3) The INCLUDE statement is long overdue, and almost didn't make it into the standard. 4) Pointers are overdue. Cray pointers are available on many platforms (Cray, Convex, Sun, some IBMs and some DEC machines), but the new Fortran Extended pointers are not the same. 5) Allocatable and automatic arrays are great. 6) It is finally done! What Next? Some vendors (including some no voters) will start working towards Fortran Extended implementations. You might see a few in 2-3 years. If these initial implementations are successful and generate public interest, Fortran Extended should be generally available in the late 1990's. Partial implementations (such as limited array notation) is available now on some implementations, and will show up on many large scientific oriented systems. Commercial systems may chose to implement modules first. You should avoid using features such as Cray pointers and VAX records (and any other Fortran 77 extensions) in the meantime, so that your code will port more easily to Fortran Extended compilers. Although it may be technically feasible for a vendor to provide for these extensions, it will add a lot of implementation effort and some risk to do so; therefore, it is unlikely that all vendors who support VAX records and Cray pointers now will support them in their Fortran Extended compilers. If you would like a more detailed discussion, come to the next X3J3 meeting and buy me a beer :-). -- ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (04/26/91)
>> On 26 Apr 91 14:22:49 GMT, bleikamp@convex.com (Richard Bleikamp) said:
Richard> The new standard has de-emphasized execution time
Richard> performance in order to make the programmer's life easier.
Richard> To do this to Fortran, long known for its good execution
Richard> speed, seems a little crazy.
On the other hand, many of us think that to *not* trade execution time
for reliability, reusability, and ease of programming it a little
crazy! You can still use the "fast" subset of Fortran Extended when
speed is critical.
Of course it is a very tough tradeoff. When I am developing
applications I curse Fortran extensively because of its archaic
structure and lack of error-checking. When I am doing science and
need 500 Cray Y/MP hours to get my work done, I curse other languages
(which have wonderful features that I would really like to use) for
not running as fast as Fortran.
--
John D. McCalpin mccalpin@perelandra.cms.udel.edu
Assistant Professor mccalpin@brahms.udel.edu
College of Marine Studies, U. Del. J.MCCALPIN/OMNETjlg@cochiti.lanl.gov (Jim Giles) (04/26/91)
In article <KHB.91Apr24234512@chiba.Eng.Sun.COM>, khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: |> In article <1991Apr25.043355.26420@ariel.unm.edu> prentice@triton.unm.edu (John Prentice) writes: |> |> Gee, good to know only the minor players voted against it. So who voted |> for it? |> |> Everyone else. The formal postmeeting distribution hasn't reached me |> yet, so I'd likely misrepresent someone if I relied on inference. |> However, in the last go round several "minor" players such as IBM, |> Amdahl, Sun, DECUS, and misc. national labs (and several foregin ones) |> voted Aye. Yes. But it would be interesting to know just which of these Aye votes were cast because of support for the language and which were cast just to get the process over with. It has been quite clear for some time that the language itself is cast in concrete. Any change of a substantial nature would be nearly impossible (not sure, but I think a 2/3 majority would have been required). That being the case, what's the point of voting against the present proposal? J. Giles
glover@sequoia.cray.com (Roger Glover) (04/27/91)
In article <MCCALPIN.91Apr26112553@pereland.cms.udel.edu>, mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: |> |> Of course it is a very tough tradeoff. When I am developing |> applications I curse Fortran extensively because of its archaic |> structure and lack of error-checking. When I am doing science and |> need 500 Cray Y/MP hours to get my work done, I curse other languages |> (which have wonderful features that I would really like to use) for |> not running as fast as Fortran. To me, this sounds like an excellent reason to keep in your toolbox: - A friendly language that catches everything but bad thinking at compile time. Take your pick for there are many. - A fast, efficient language that can carry the workload. To me this is obviously Fortran 77, although some would argue that Standard C with Cray extensions (intrinsic complex data type, automatic and adjustable arrays (3.0), and "restricted" pointers (3.0)) will do in a pinch. ----------------- Roger Glover Software Instructor Cray Research, Inc. Disclaimer: These opinions are mine, not Seymour's.
jlg@cochiti.lanl.gov (Jim Giles) (04/27/91)
In article <1991Apr25.140056.5438@convex.com>, psmith@convex.com (Presley Smith) writes: |> [...] |> The situation is similar to an election for something like the President |> of the United States... Even if I didn't vote for the person who is |> elected, once he/she is the president, I will support that person. I |> still may not agree with all he/she stands for but he/she is the president. That is one possible interpretation. Personally, I think the reverse will be true for Fortran 90. A number of Aye votes may have just represented a weary desire to get the 'election' over with (real elections don't drag out like standards committees do). Even those voting Aye may have done so because they finally decided the best venue to fight the adoption of Fortran 90 is now the marketplace and not the committee. J. Giles
vsnyder@jato.jpl.nasa.gov (Van Snyder) (04/27/91)
In article <1991Apr25.235111.26282@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >Before I write anything more, I wish to make it clear that I am just >trying to satisfy my curiosity. I do not wish in any way to denigrate >the efforts nor to question the motives of anyone on X3J3. > >In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM >(Keith Bierman fpgroup) writes: >> *) I believe that the vote was 26-9 to accept the document as it >> stood after the edits... > >Why would anyone vote against the standard at this late date? Are there >outstanding technical problems with the standard which these objectors >felt needed to be adressed before the standard is released? > One of the NO voters has informed me a great part of the decision to vote no was because of the poor quality of exposition in the standard document. At least I have one ear on the committee who agrees with me. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
buckland@cheddar.ucs.ubc.ca (Tony Buckland) (04/27/91)
In article <15972@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: > >What are the relative merrits of smaller, incremental changes every >5-6 years, versus these monstrous rewrights every 12-15 years? Smaller or more incremental, or not, I'd expect them to argue just as long, and I'd expect the formal rituals to take just as long; I doubt they could complete *any* change in a mere 5-6 years. Point (ii) is that with a change every decade or so we get a chance to use each version for a while before the next one starts looming on the horizon.
prentice@triton.unm.edu (John Prentice) (04/27/91)
I read all these postings today with interest. Several things struck me. First, the late 1990's is too long to have to wait for compilers to finally implement features long available in other languages like C. I have to question whether Fortran Extended is really worth waiting for or if the time hasn't come to switch to something else. Second, the discussion on efficiency continues to skirt what I would regard as the major issue in scientific computing - parallelism. What about Fortran Extended is going to improve performance on parallel systems, of whatever type? I guess the real question is: is there any convincing argument for staying with Fortran for new compute intensive parallel codes, much less waiting 10 years for someone to finally write me a compiler for it? That is not a rhetorical question, we are in the middle of an enormous software project and this issue is getting serious for us. In the past I have defended Fortran pretty seriously, but I have got to tell people, it looks more and more like it is getting left behind by the sweeping technical advances occuring in high performance computing. The standardization debates are focusing on standardizing practices that have been around now for years, as they should. But in the meantime the needs of the scientific programmer are changing very quickly and if the language is slow to change, it may very well become obsolete. I say this while noting that no other language seems to me to have established itself the clear winner for high performance computing, particularly on massively parallel systems. But I don't see Fortran even being in the running at the moment. If there are arguments I am missing, I would like to hear them. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
psmith@convex.com (Presley Smith) (04/27/91)
In article <1991Apr26.210247.17264@ariel.unm.edu> prentice@triton.unm.edu (John Prentice) writes: >I read all these postings today with interest. Several things struck me. >First, the late 1990's is too long to have to wait for compilers to >finally implement features long available in other languages like C. >I have to question whether Fortran Extended is really worth waiting for >or if the time hasn't come to switch to something else. Second, the >discussion on efficiency continues to skirt what I would regard as the >major issue in scientific computing - parallelism. What about Fortran >Extended is going to improve performance on parallel systems, of whatever >type? I guess the real question is: is there any convincing argument >for staying with Fortran for new compute intensive parallel codes, much >less waiting 10 years for someone to finally write me a compiler for it? >That is not a rhetorical question, we are in the middle of an enormous >software project and this issue is getting serious for us. > Fortran 90 does not address the issue of parallelism. A separate group was formed called the Parallel Computing Forum to address a shared memory form of parallelism for Fortran and other langauges. PCF has since become the X3H5 committee and appears about ready to publish their first draft since it's been an ANSI Committee. That committee is defining parallel syntax and semantics for FORTRAN 77. To my knowledge, they have not addressed Fortran 90 yet. So, if you want parallelism in the near term, you'll have to look somewhere else... Fortran 90 does not solve that problem. FYI.
prentice@triton.unm.edu (John Prentice) (04/27/91)
In article <1991Apr27.013231.27187@convex.com> psmith@convex.com (Presley Smith) writes: > >So, if you want parallelism in the near term, you'll have to look >somewhere else... Fortran 90 does not solve that problem. > Yep, precisely my point. Now, given that Fortran is regarded mostly, if not exclusively, as a scientific language and given that parallelism is rapidly becomeing standard for scientific computing, where does that leave Fortran? If it fails to address the needs of the scientific community, it will get left behind. I am not trying to trash the development of standards here, but I am pointing out that the process may very well destroy the language, particularly if standards take 14 years to even agree on and another 8 or 9 to implement. I don't know what the solution is, but I am pretty confident that the system is totally out of whack as it stands. It is interesting to me that many, if not most, people I know in computing complain about how the IBM PC terribly retarded the micro industry by locking into a poor technology. I know others who complain bitterly about UNIX because it is a very old operating system. Yet we enshrine the concept of going slow and knowingly retarding the technology with language standards. There are good arguments for all this, but they implicitly are based on the idea that things will not change too rapidly. But the computer industry IS changing very rapidly and I quite expect that very few of the old standby languages like Fortran and C are going to be serious players in the future, just because they are inherently too slow to accommodate the changing needs of the community. My conclusion? Like it or not, get used to learning and adapting to new languages until such time, if ever, things stabilize again. I don't like that conclusion, but I don't see any alternatives for scientists trying to stay on the leading edge of computing. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
ian@argosy.UUCP (Ian L. Kaplan) (04/28/91)
>Second, the >discussion on efficiency continues to skirt what I would regard as the >major issue in scientific computing - parallelism. What about Fortran >Extended is going to improve performance on parallel systems, of whatever >type? >-- >John K. Prentice john@unmfys.unm.edu (Internet) >Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA >Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA Fortran 90 is indeed a complex language whose implementation is not entirely understood. As with any compromise, it can be criticized from a number of perspectives. However, I do not believe that it is reasonable to criticize Fortran 90 because it does not support MIMD parallelism. I think that it would have been very difficult, if not impossible, to get a group as large as the Fortran Standards Committee to agree on features for MIMD parallelism. There is not much in the way of "industry practice" in this area and few people will agree on what constitutes a "good" feature. Some of the differing view points stem from the diversity in MIMD systems, which range from shared memory systems, to cubes, to mesh connected machines. These machines will all have different communication latencies which may influence how they are programmed. With the exception of experimental languages like SISAL, Id and Lucid, I don't know of any languages that would work well across a range of MIMD machines. C++ was mentioned. However, I suggest that some though should be given to how "parallel C++" would be mapped onto both shared memory (e.g., Alliant or Sequent machines) and distributed memory (e.g., cubes) MIMD machines before making such claims. A final note: while Fortran 90 does nothing to support MIMD programming, the array syntax in Fortran 90 does map pretty well onto SIMD architectures and is supported by both MasPar and Thinking Machines in their Fortran compilers. Ian Kaplan MasPar Computer Corp. The above is the personal opinion of the author.
campbell@dev8n.mdcbbs.com (Tim Campbell) (04/29/91)
Richard;
Thanks for that insightful post on Fortran 90. I've long been hearing rumors
about it and have been trying to learn exactly what it will do.
I was especially happy to read the features in "What's good about Fortran
Extended ?". I was especially happy to see structures and pointers made it
into the standard <thank God>.
I do have one little thing I absolutely drives me nuts about Fortran 77 and I
hope it's been addressed: Prototyping! The fact that any procedure
can be called with any arguments (even if they're wrong) and no errors are
generated. I have used an HP "lint" program for Fortran (called flint) which
did _attempt_ to address this problem, although it still had problems because
it issued error messages whenever a single argument to an aggregate (array) was
passed where a scaler was expected. After all, I'm only passing a single
element where one is expected... why should I get an error? I could forgive
this, except it's particularly annoying when trying to debug a problem in a
program with 26000 procs (it's a big program) - and it's difficult to wade
through all those illegitimate errors in search of the real thing.
Are you "in the know" on this one? Will Fortran 90 tell me if I try to pass
arguments to a subroutine which doesn't match the type of arguments expected?
More insight is appreciated. I owe you a beer (although I don't see myself
making it to a standards meeting anytime soon).
-Tim
---------------------------------------------------------------------------
In real life: Tim Campbell - Electronic Data Systems Corp.
Usenet: campbell@dev8.mdcbbs.com @ McDonnell Douglas M&E - Cypress, CA
also: tcampbel@einstein.eds.com @ EDS - Troy, MI
CompuServe: 71631,654 (alias 71631.654@compuserve.com)
#include <std/disclaimers.h>jlg@cochiti.lanl.gov (Jim Giles) (04/29/91)
In article <1266@argosy.UUCP>, ian@argosy.UUCP (Ian L. Kaplan) writes: |> [...] |> I think that it would have been very difficult, if not impossible, |> to get a group as large as the Fortran Standards Committee to agree on |> features for MIMD parallelism. There is not much in the way of |> "industry practice" in this area and few people will agree on what |> constitutes a "good" feature. [...] Yes. All valid reasons for not jumping to some feature too quickly. However, none of these arguments seem relevant to the actual features that the committee _did_ adopt. There seems to have been little attention to "industry practice" in the design of features for Fortran Extended. And, several features were added for which few people agree about what constitutes a "good" feature. Since the committee didn't follow these guidelines for the features they _did_ put in, why shouldn't they also include some coarse-grained parallelism support? J. Giles
alm@lanl.gov (Alex Marusak) (04/30/91)
> From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) > Subject: Re: Fortran 90 status > > In article <1991Apr25.043355.26420@ariel.unm.edu> prentice@triton.unm.edu > (John Prentice) writes: > > > In article <KHB.91Apr24160852@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM > > (Keith Bierman fpgroup) writes: > > > > > I believe that the vote was 26-9 to accept the document as it stood after > > > the edits. Two copies of the marked up document were carried to Walt > > > Brainerd (by two different X3J3 members, to protect against lossage due to > > > a plane crash). Voting against were the reps from: Microsoft, Convex, > > > Cray, Lahey, Harris, DoD, Boeing, Unisys and DEC. > > > > Gee, good to know only the minor players voted against it. So who voted for > > it? > > Everyone else. The formal postmeeting distribution hasn't reached me yet, so > I'd likely misrepresent someone if I relied on inference. However, in the last > go round several "minor" players such as IBM, Amdahl, Sun, DECUS, and misc. > national labs (and several foreign ones) voted Aye. A comment from a voting member from a national lab: I voted 'no' several votes back, when the pivotal votes were being taken (around the time of the first and second public reviews). Back then, I thought Fortran 90 was an unworthy successor to Fortran 77. I still do. I thought X3J3 responded inadequately to the comments from the first public review. I still believe this. However, the majority of X3J3 seems determined to proceed with Fortran 90. To my way of thinking, the recent votes are merely votes to forward the latest set of edits, bug fixes, clarifications, and the occasional substantive jury-rig, such changes to be included in the PREVIOUSLY-FORWARDED proposed new standard. In other words, if the majority of X3J3 wishes to persist in this mistake, then X3J3 should at least forward the best-edited, bug-free, clearest mistake that it is capable of producing. On that basis, I now vote 'yes'. Besides, I may be wrong. Fortran 90 may become wildly popular. Even though it is an unwieldy mixture of ideas (the old and the really old), largely appealing neither to the cutting-edge, computer-science types nor to the traditional, efficiency-hungry, bit-twiddling, 'full contact' sort of programmers Fortran is famous for, perhaps it will find a niche. And I will be very, very surprised. > From: prentice@triton.unm.edu (John Prentice) > Subject: Re: Fortran 90 status > > If Fortran Extended is not going to be recognized outside the U.S., then why > are foreign reps voting on it (or am I confused about what is the U.S. > standard versus the international one - ugh) ? Anyone know what the votes of > the DOE labs were? Fortran Extended is a creation of our parent organization, X3. X3 is a U.S. organization. Several X3J3 members objected to X3's actions and said so. Some X3J3 members approved; that is, approved of the U.S. keeping Fortran 77 and of adopting Fortran 90 at such time as the international community does. DOE labs, votes: LANL (Los Alamos) - yes (but see above) LLNL (Lawrence Livermore) - yes INEL (Idaho Falls) - yes. In the past, LBNL (Lawrence Berkeley) and ANL (Argonne) have voted 'yes'. Perhaps LBNL still does (I lose track).
vsnyder@jato.jpl.nasa.gov (Van Snyder) (04/30/91)
In article <1266@argosy.UUCP> ian@bear.UUCP (Ian L. Kaplan) writes: >>Second, the >>discussion on efficiency continues to skirt what I would regard as the >>major issue in scientific computing - parallelism. What about Fortran >>Extended is going to improve performance on parallel systems, of whatever >>type? >>-- >>John K. Prentice john@unmfys.unm.edu (Internet) >>Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA >>Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA ...[stuff deleted] > With the exception of experimental languages like SISAL, Id and >Lucid, I don't know of any languages that would work well across a >range of MIMD machines. C++ was mentioned. However, I suggest that >some though should be given to how "parallel C++" would be mapped onto >both shared memory (e.g., Alliant or Sequent machines) and distributed >memory (e.g., cubes) MIMD machines before making such claims. ... > Ian Kaplan > MasPar Computer Corp. It's nice to see at last some more folks concluding that dataflow languages hold more promise for MIMD machines. The problem with languages born of sequential computing, and then modified to try to cope with MIMD computing is that it's almost impossible to do the time & data dependency analysis a priori. Putting in BARRIER and PARDO won't be much help if you leave an important one out: it doesn't much matter how effectively your program uses the processors if it unpredictably gets subtly wrong answers. BTW, Dave Culler, the author of the Id compiler at the Computation Structures Group at MIT, now at Berkeley, has an Id -> C translator, and is working closely with Ncube to improve the message-passing stuff in their OS, presumably to take advantage of the fact that messages in dataflow context are of fixed length. With his hacked-up prototype, he's taking about 3-10 times as long as a C program to do the same computation, but still about 3-10 times as fast as an equivalent lisp program. Once he gets a REAL compiler cranked up on something like an Ncube, the enormous quantities of unstructured parallelism, as compared to the puny amounts of structured parallelism, in typical math software should make MIMD a real barn burner. And a lot easier to program than using a bastardized sequential language. Just my opinion. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
chidsey@smoke.brl.mil (Irving Chidsey) (04/30/91)
In article <1991Apr26.200903.1938@unixg.ubc.ca> buckland@cheddar.ucs.ubc.ca (Tony Buckland) writes: <In article <15972@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: <> <>What are the relative merrits of smaller, incremental changes every <>5-6 years, versus these monstrous rewrights every 12-15 years? < < Smaller or more incremental, or not, I'd expect them to argue just < as long, and I'd expect the formal rituals to take just as long; < I doubt they could complete *any* change in a mere 5-6 years. Then the process will grind to a halt during the next change or so, and the language will fossilize. Another alternative will be for the standardization process to grind to a halt with the language continuing to grow and dividing into increasingly incompatible dialects. Either bodes ill for the future of Fortran. < Point (ii) is that with a change every decade or so we get a < chance to use each version for a while before the next one starts < looming on the horizon. Then perhaps the process should spend more effort on standardizing things that have been shown to work well, and less on trying to predict what god would choose if he were writing fortran. The standards committee should work hard to standardize what works, it should put some effort in to guiding future practice, but it should not be afraid of saying 'we were not able to agree on what would be the best way of these things, but we do agree they should be tried.' Irv -- I do not have signature authority. I am not authorized to sign anything. I am not authorized to commit the BRL, the DA, the DOD, or the US Government to anything, not even by implication. They do not tell me what their policy is. They may not have one. Irving L. Chidsey <chidsey@brl.mil>
maine@altair.dfrf.nasa.gov (Richard Maine) (04/30/91)
On 29 Apr 91 14:02:41 GMT, campbell@dev8n.mdcbbs.com (Tim Campbell) said:
Tim> I do have one little thing I absolutely drives me nuts about
Tim> Fortran 77 and I hope it's been addressed: Prototyping! The fact
Tim> that any procedure can be called with any arguments (even if
Tim> they're wrong) and no errors are generated.
...
Tim> Are you "in the know" on this one? Will Fortran 90 tell me if I
Tim> try to pass arguments to a subroutine which doesn't match the
Tim> type of arguments expected?
Yep. Well, more properly the answer is "it depends." Fortran 90 will
provide diagnostics for such errors if the subroutine "interface is
explicit," to use the terminology of the standard. There are several
ways to make sure that your interfaces are explicit; one nice one is
to put all of your subroutines in modules.
Note also that the Fortran 90 standard explicitly requires compilers
to be able to give diagnostics for such errors. The Fortran 77
standard does not require that the compiler do anything at all useful
if you have an error. If a Fortran 77 compiler fails to give an error
message for blatantly illegal code, you have no recourse in the standard.
You can, of course, bitch about the quality of implementation, but not
about a standard violation.
--
--
Richard Maine
maine@altair.dfrf.nasa.govrrr@u02.svl.cdc.com (Rich Ragan) (04/30/91)
In <1991Apr29.140241.1@dev8n.mdcbbs.com> campbell@dev8n.mdcbbs.com (Tim Campbell) writes: >Are you "in the know" on this one? Will Fortran 90 tell me if I try to pass >arguments to a subroutine which doesn't match the type of arguments expected? >More insight is appreciated. I owe you a beer (although I don't see myself >making it to a standards meeting anytime soon). Fortran 90 does include a procedure interface block so that you can say things like INTERFACE SUBROUTINE SWITCH (X, Y, Z) INTEGER, INTENT (IN) :: X REAL, INTENT (OUT) :: Y REAL, INTENT (INOUT) :: Z(10) END SUBROUTINE SWITCH END INTERFACE This gives the compiler the information necessary to do the kind of checking that you want. The INTENT declarations are new with Fortran 90 and let you specify if the dummy argument is read only, write only, or both. This form of interface declaration is intended for use with existing external subprograms and functions. If you were writing from scratch with Fortran 90, a better way to do this would be to build one or more MODULE subprograms containing your library routines. Then you would specify the use of a particular module when you needed its routines (e.g, string handling module) and the compiler could obtain the interface checking information directly from the module rather than you having to write explicit INTERFACE blocks. -- Richard R. Ragan rrr@svl.cdc.com (408) 496-4340 Control Data Corporation - Silicon Valley Operations 5101 Patrick Henry Drive, Santa Clara, CA 95054-1111
jlg@cochiti.lanl.gov (Jim Giles) (04/30/91)
In article <1991Apr29.140241.1@dev8n.mdcbbs.com>, campbell@dev8n.mdcbbs.com (Tim Campbell) writes: |> Richard; |> [...] |> I was especially happy to read the features in "What's good about Fortran |> Extended ?". I was especially happy to see structures and pointers made it |> into the standard <thank God>. I was one of the people who suggested pointers in the first public review (like most others I hear). However, if I had known what they were going to do with them I would never have suggested them. The Fortran 90 proposal contains the _worst_ pointer definition that I have ever seen in a programming language. The use of pointers to array slices is a practice which in years to come will rank with implicit equivalencing through COMMON as a practice to be avoided at all cost. |> [...] |> I do have one little thing I absolutely drives me nuts about Fortran 77 and I |> hope it's been addressed: Prototyping! [...] Yes! The proposal does include a feature called "interface specifications" which perform this function. Not only that, but since the arguments are type checked at compile time, the interface specifications provide a means of overloading a single procedure name for generic operation. Here are some examples from the proposed standard document (June 1990): INTERFACE SUBROUTINE EXT1 (X, Y, Z) REAL, DIMENSION (100, 100) :: X, Y, Z END SUBROUTINE EXT1 SUBROUTINE EXT2 (X, Z) COMPLEX (KIND=4) Z(2000) END SUBROUTINE EXT2 FUNCTION EXT3 (P, Q) LOGICAL EXT3 INTEGER P(1000) LOGICAL Q(1000) END FUNCTION EXT3 END INTERFACE The arguments to each of these procedures must match the definitions given in the interface as far as type _and_ size (the array arguments must be conformable to the sizes given - an unspecified size would be denoted by a colon (:) as the size in the interface). When a procedure has been 'interfaced', you can call it with keywords for the arguments: EXT3 (Q = P_MASK (N+1 : N+1000), P = ACTUAL_P) Generic procedures are implemented by giving several different interfaces in a named interface specification block: INTERFACE SWITCH SUBROUTINE INT_SWITCH (X, Y) INTEGER INTENT (INOUT) :: X, Y END SUBROUTINE INT_SWITCH SUBROUTINE REAL_SWITCH (X, Y) REAL INTENT (INOUT) :: X, Y END SUBROUTINE REAL_SWITCH SUBROUTINE COMPLEX_SWITCH (X, Y) COMPLEX INTENT (INOUT) :: X, Y END SUBROUTINE COMPLEX_SWITCH END INTERFACE Now you can call SWITCH with any of the three argument configurations and the compiler will automatically select the correct version to use: CALL SWITCH (MAX_VAL, LOC_VAL) ! MAX_VAL and LOC_VAL are of type INTEGER |> [...] Will Fortran 90 tell me if I try to pass |> arguments to a subroutine which doesn't match the type of arguments expected? A Fortran 77 implementation _could_ have been doing this all along. The problem is that checking that the arg types match was a job that the _compiler_ couldn't do because it couldn't make use of interprocedural knowledge (and remain compatible with the possibility of separate compilation). That being the case, the job could only have been done at load-time or run-time. Nobody wanted to pay for the run-time check, and loaders never bothered to do it (probably because _some_ people actually want to cheat the type checking in this way - that's the problem with not giving the user an _explicit_ way to defeat type checking). Obviously, procedures with interface specifications can (and actually _must_) check the argument types. This can be done at compile time. J. Giles
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/02/91)
In article <22900@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: > A Fortran 77 implementation _could_ have been doing this all > along. The problem is that checking that the arg types match > was a job that the _compiler_ couldn't do because it couldn't > make use of interprocedural knowledge (and remain compatible > with the possibility of separate compilation). That being the > case, the job could only have been done at load-time or run-time. > Nobody wanted to pay for the run-time check, and loaders never > bothered to do it (probably because _some_ people actually want > to cheat the type checking in this way - that's the problem with > not giving the user an _explicit_ way to defeat type checking). This is not quite true. The Burroughs B6700 Fortran compiler did just such a check, and always did so even before there _was_ a B6700. What's more, the compiler _did_ check calls to routines that were in the same source file. No, this did _not_ make anything incompatible with the possibility of separate compilation. Burroughs object files contained full symbol tables. (UNIX object files may do so too. I have never understood why UNIX compilers didn't exploit this.) This facility caught a lot of mistakes, even in code that had allegedly been ``working'' on other machines. When I had to use the Prime Fortran compiler, I was very surprised (not to say dismayed) to find that it didn't do something so obvious (and, having read the source code of the Burroughs compilers and binder, so _easy_). Then I found that this was current practice, and stopped thinking badly of Prime and started thinking highly of Burroughs. Note that you don't need any special facility built into the loaders. UNIX C++ compilers get a lot of mileage out of constructing names that have the types built in (this was described in SP&E a long time ago), just as one feature of the Burroughs compiler was that a subroutine called FRED was known to the binder as "FRED", while a common block called FRED was known to the binder as "/FRED/". -- Bad things happen periodically, and they're going to happen to somebody. Why not you? -- John Allen Paulos.
jlg@cochiti.lanl.gov (Jim Giles) (05/02/91)
In article <5526@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: |> In article <22900@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: |> > [... type checking arguments to procedures ...] |> |> [...] The Burroughs B6700 Fortran compiler did just |> such a check, and always did so even before there _was_ a B6700. What's |> more, the compiler _did_ check calls to routines that were in the same |> source file. No, this did _not_ make anything incompatible with the |> possibility of separate compilation. [...] The type check itself could easily be made obsolete by later recompiling just one of the procedures that was formerly in the same source file. Separate compilation in Fortran makes no mention of 'files' at all. So, depending on information from within the same source file is not sufficient to be _sure_ of type match. |> [...] Burroughs object files contained |> full symbol tables. (UNIX object files may do so too. I have never |> understood why UNIX compilers didn't exploit this.) This is why it's easy to do this in the loader. The information is usually there (in the symbol tables). Further, the information is in its final form: all the compilation is done by the time the loader runs. J. Giles
rrr@u02.svl.cdc.com (Rich Ragan) (05/03/91)
In <23069@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >This is why it's easy to do this in the loader. The information is >usually there (in the symbol tables). Further, the information is >in its final form: all the compilation is done by the time the loader >runs. This is exactly what we do in the Control Data Cyber 180 Fortran. The compiler has an option to generate caller/callee information tables. At load time, the loader will report type mismatches, usage mismatches (e.g., storing into a constant or an expression result), scalar/array mismatches (e.g. passing a variable to an array), and probably a couple of other checks I can't remember off the top of my head. It works quite well and the loader tables get chucked when the fully bound production version is generated so you don't have any space cost in production binaries. -- Richard R. Ragan rrr@svl.cdc.com (408) 496-4340 Control Data Corporation - Silicon Valley Operations 5101 Patrick Henry Drive, Santa Clara, CA 95054-1111
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (05/03/91)
In article <MAINE.91Apr30075412@ra.dfrf.nasa.gov>, maine@altair.dfrf.nasa.gov (Richard Maine) writes: >On 29 Apr 91 14:02:41 GMT, campbell@dev8n.mdcbbs.com (Tim Campbell) said: > >Tim> I do have one little thing I absolutely drives me nuts about >Tim> Fortran 77 and I hope it's been addressed: Prototyping! The fact >Tim> that any procedure can be called with any arguments (even if >Tim> they're wrong) and no errors are generated. > > ... > >Tim> Are you "in the know" on this one? Will Fortran 90 tell me if I >Tim> try to pass arguments to a subroutine which doesn't match the >Tim> type of arguments expected? > >Yep. Well, more properly the answer is "it depends." A number of others have already responded with comments about the Fortran 90 INTERFACE declarations, and how they will help ensure a match between your actual and dummy parameters. Fortran 90 also allows for optional parameters, and keyword parameters, a couple of related features that can help keep your code neat and clean. I can still recall using subroutines with way too many parameters, many of which were only used in certain cases. Now (well, actually at some time in the future) we will be able to leave out the optional parameters in the call statement or function reference instead of having to make up a bunch of phony variables and constants just to hold places Actual parameter lists will also be more self documenting if given in keyword form, i.e.: call drawvec(type='2d', xbgn=wl, ybgn=wb, & xend=wr, yend=wt) call drawvec(type='3d', xbgn=zx1, xend=zx2, & ybgn=zy1, yend=zy2, & zbgn=zz1, zend=zz2) Note that the order in which parameters appear is not fixed, so you can use any order that makes sense. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------
bill@hcx2.ssd.csd.harris.com (Bill Leonard) (05/04/91)
In article <1991Apr26.210247.17264@ariel.unm.edu>, prentice@triton.unm.edu (John Prentice) writes: > In the past I have defended Fortran pretty seriously, but I have got to > tell people, it looks more and more like it is getting left behind by > the sweeping technical advances occuring in high performance computing. > The standardization debates are focusing on standardizing practices > that have been around now for years, as they should. But in the meantime > the needs of the scientific programmer are changing very quickly and > if the language is slow to change, it may very well become obsolete. > I say this while noting that no other language seems to me to have > established itself the clear winner for high performance computing, > particularly on massively parallel systems. But I don't see Fortran > even being in the running at the moment. If there are arguments I > am missing, I would like to hear them. I've heard these complaints many times, and each time I wonder if people really realize what they are asking for. It seems that programmers (of whatever persuasion) want all (or most) of the following: 1. A modern language with lots of built-in safety (i.e., error checking). 2. A language that supports the latest whiz-bang design methodology (i.e., data hiding, object-oriented, etc.). 3. A language that runs like a bat out of hell. 4. A language that is standard across the entire range of architectures. 5. A language that takes advantage of the latest hardware and programming technology (i.e., dataflow machines, massively parallel architectures, etc.). 6. Cheap compilers and tools. 7. Availability tomorrow (that is, the day after you just bought the latest and greatest whiz-bang computer). Now let's be honest -- does anyone really believe this is possible? Let's look at recent history. Ada was supposed to provide much of these features (but not all). At the time Ada was designed, data hiding and modularity were the latest "fad" in software engineering. By the time Ada compilers were widely available, data hiding was passe and object-oriented design and programming were the "in" thing. Languages, especially ones that provide (1) and (4), take time to design. Compilers and tools for them take time, and money, to build. It takes time to learn what you did right (in the language design) and what you did wrong. (The Ada tasking model is a good example of this kind of education.) I think it's time we took a big dose of realism. Let's realize that the science of building hardware, as well as research into programming methodology, is advancing at a pace that far exceeds the ability of _standard_ (note the emphasis) languages to keep up. That is not to say that we shouldn't build those machines or use those methodologies. But let's not expect everything tomorrow. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com --------------------------------------------------------------------------- "Chronologically gifted" -- new government term for "old". Does this make babies "chronologically deprived"? ---------------------------------------------------------------------------
prentice@triton.unm.edu (John Prentice) (05/10/91)
In article <3246@travis.csd.harris.com> bill@hcx2.ssd.csd.harris.com (Bill Leonard) writes: > >I've heard these complaints many times, and each time I wonder if people >really realize what they are asking for. It seems that programmers >(of whatever persuasion) want all (or most) of the following: > > 1. A modern language with lots of built-in safety (i.e., error checking). > > 2. A language that supports the latest whiz-bang design methodology > (i.e., data hiding, object-oriented, etc.). > > 3. A language that runs like a bat out of hell. > > 4. A language that is standard across the entire range of architectures. > > 5. A language that takes advantage of the latest hardware and programming > technology (i.e., dataflow machines, massively parallel architectures, > etc.). > > 6. Cheap compilers and tools. > > 7. Availability tomorrow (that is, the day after you just bought the > latest and greatest whiz-bang computer). > > [stuff deleted]... > >let's not expect everything tomorrow. > Bill's points are well taken, but I would make two comments. The first is that at least so far as my appeal went, I am not asking for all the things listed above. Quite the contrary. I am willing to live with much inconvience and lack of portability if that is the price I pay for really superior performance. I run on supercomputers for only one reason, to run the largest physics problem I can. I need a good six orders of magnitude increase in speed to really do the problems I would like to do in condensed matter physics. We will get two or three of those in just the next couple years with the new CM (if the new machines live up to their billing). One might hope 6 is not an eternity away. But to exploit that speed, I need languages that address parallelism. They don't have to be cheap however. They don't have to be portable. They don't have to be easy to use (in some sense). And they most certainly don't have to be safe. I would like all these things, but the only times the Fortran community has ever had them is during periods of relative hardware stagnation. The rest of the time, this is the way it has always been. My other comment is really more to the point however. The real issue is that if we keep going the way we are, Fortran is going to become so obsolete that it is no longer viable. 15 to 20 years between modernizations of the language is too long. I still advocate either frequent updates to the standard which incorporate existing practice or alternately just giving up on the whole concept of standards. I know there are lots of arguments against both ideas, but I haven't yet heard a suggestion that is any better. This much is for sure however, the current system doesn't work. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
dedina@cup.portal.com (Michael J Dedina) (05/10/91)
>In article <3246@travis.csd.harris.com> bill@hcx2.ssd.csd.harris.com (Bill Leo nard) writes: >> >>I've heard these complaints many times, and each time I wonder if people >>really realize what they are asking for. It seems that programmers >>(of whatever persuasion) want all (or most) of the following: >> >> 1. A modern language with lots of built-in safety (i.e., error checking). >> >> 2. A language that supports the latest whiz-bang design methodology >> (i.e., data hiding, object-oriented, etc.). >> >> 3. A language that runs like a bat out of hell. >> >> 4. A language that is standard across the entire range of architectures. >> >> 5. A language that takes advantage of the latest hardware and programming >> technology (i.e., dataflow machines, massively parallel architectures, >> etc.). >> >> 6. Cheap compilers and tools. >> >> 7. Availability tomorrow (that is, the day after you just bought the >> latest and greatest whiz-bang computer). >> >> [stuff deleted]... >> >>let's not expect everything tomorrow. >> > >Bill's points are well taken, but I would make two comments. The first is >that at least so far as my appeal went, I am not asking for all the things >listed above. Quite the contrary. I am willing to live with much inconvience >and lack of portability if that is the price I pay for really superior >performance. > > [stuff deleted] > >might hope 6 is not an eternity away. But to exploit that speed, I need >languages that address parallelism. They don't have to be cheap however. >They don't have to be portable. They don't have to be easy to use (in some >sense). And they most certainly don't have to be safe. I would like all >these things, but the only times the Fortran community has ever had them is >during periods of relative hardware stagnation. The rest of the time, this >is the way it has always been. > >My other comment is really more to the point however. The real issue is that >if we keep going the way we are, Fortran is going to become so obsolete that >it is no longer viable. 15 to 20 years between modernizations of >the language is too long. I still advocate either frequent updates to the >standard which incorporate existing practice or alternately just giving >up on the whole concept of standards. I know there are lots of arguments >against both ideas, but I haven't yet heard a suggestion that is any >better. This much is for sure however, the current system doesn't work. > >John >-- >John K. Prentice john@unmfys.unm.edu (Internet) >Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA >Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA I don't understand your point. If you don't need portability, why is it necessary for you to wait for the *standard* to introduce parallel features? The vendors will (and already have) introduce parallel features into their compilers before it gets put into the standard. Fortran *does* get modernized continuously; it just doesn't get standardized continuously. Mike Dedina dedina@cup.portal.com
maine@altair.dfrf.nasa.gov (Richard Maine) (05/10/91)
On 10 May 91 00:23:37 GMT, prentice@triton.unm.edu (John Prentice) said: John> that at least so far as my appeal went, I am not asking for all John> the things listed above. Quite the contrary. I am willing to John> live with much inconvience and lack of portability if that is John> the price I pay for really superior performance. John> ... I need a good six orders of magnitude increase in speed John> ... But to exploit that speed, I need languages that address John> parallelism. They don't have to be cheap however. They don't John> have to be portable. They don't have to be easy to use (in some John> sense). And they most certainly don't have to be safe. John> if we keep going the way we are, Fortran is going to become so John> obsolete that it is no longer viable. 15 to 20 years between John> modernizations of the language is too long. I still advocate John> either frequent updates to the standard which incorporate John> existing practice or alternately just giving up on the whole John> concept of standards. I certainly agree that 15 to 20 years is too long and that, in particular, F90 should have been out about 5 years ago. However, I think John asks too much of a standard. One of the primary reasons for having a standard is portability - both in terms of code portability and programmer relearning time. A standard that is not portable is almost a contradiction, and a standard that changes too often also defeats too much of its purpose (at 14 years from 1978 to 1992(estimated), I agree that we are nowhere near the boundary of too often). This does not mean that there is no role for languages or language features that are non-portable and take intimate advantage of the newest hardware. John argues persuasively that he needs such a language and I see no reason to disagree. I just think that what he is talking about is not and can not reasonably be the role of the Fortran standard. It is more in the role of those experimental languages that might provide some of the "existing practice" on which to base the following standard. That "existing practice" does have to come from somewhere. Yes, to get top performance from the newest hardware, you may give up many of the benefits of using an established standard. You may have to put up with non-portable code, lots of time spent in learning proficiency in a new specialized language or feature, expensive software (because of low volume), and other problems. Some of these problems can be ameliorated; others are just part of the cost of doing what you have to do. This being said, there is still a role for standard Fortran (or other standardized languages). The kinds of requirements John describes, although legitimate, are not universal. There are still plenty of applications, where portability, maintainability, and others of the characteristics that John is willing to give up are paramount. In some of these kinds of applications, the role of the standard is crucial, to the extent that you are forced to stick with the standard even when there are demonstrably superior ways of doing the job on a specific system. I guess my posting amounts to mostly yet another "use whatever tool seems best for your application" message. -- -- Richard Maine maine@altair.dfrf.nasa.gov
chidsey@smoke.brl.mil (Irving Chidsey) (05/11/91)
In article <1991May10.002337.22669@ariel.unm.edu> prentice@triton.unm.edu (John Prentice) writes:
<
<My other comment is really more to the point however. The real issue is that
<if we keep going the way we are, Fortran is going to become so obsolete that
<it is no longer viable. 15 to 20 years between modernizations of
<the language is too long. I still advocate either frequent updates to the
<standard which incorporate existing practice or alternately just giving
<up on the whole concept of standards. I know there are lots of arguments
<against both ideas, but I haven't yet heard a suggestion that is any
<better. This much is for sure however, the current system doesn't work.
<
<John K. Prentice john@unmfys.unm.edu (Internet)
Most of us don't need the ultimate in powe, speed, and memory
very often. We are more apt to need ease and safety in programming.
I do not think the needs of us rabble need to be in conflict with the
needs of people like John. He needs a standard fortran, modified to
fit a state of the art computer architecture and extend it to the utmost.
Could we not agree to add to Fortran every 5 years or so those
new constructs which have proven to be valuable, discuss those directions
that might be desirable to explore next, but to only standardize on that
which was proven? A variety of architectures is likely to require a variety
of extensions, and too early standardization might preclude easy exploitation
of features that are not understood, or even considered, at what are now
over delayed updates to Fortran.
Irv
--
I do not have signature authority. I am not authorized to sign anything.
I am not authorized to commit the BRL, the DA, the DOD, or the US Government
to anything, not even by implication. They do not tell me what their policy
is. They may not have one. Irving L. Chidsey <chidsey@brl.mil>mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (05/13/91)
In article <16101@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: > Could we not agree to add to Fortran every 5 years or so those >new constructs which have proven to be valuable, discuss those directions >that might be desirable to explore next, but to only standardize on that >which was proven? I think this is an interesting idea. I hope Irving doesn't mind if I expand on it a bit. The current standard has two categories of constructs: "general" and "deprecated". (I'm not sure what terminology the standard actually uses. I trust my usage is clear enough. The second class corresponds to old language features retained only for compatibility and which may be removed in the next round of standardization, while the first category refers to everything else.) Perhaps the next round should have three classes: "general", "deprecated" and "exploratory". Implementation of exploratory features would be encouraged, but not required. We could throw into this new category anything we're not sure about but would like to try. We could probably agree on exploratory features faster than we could agree on general features since they wouldn't be perceived to be cast in stone. Exploratory features would also allow vendors who thought that the particular version espoused by the standard was somehow wrong (inefficient, or whatever) to explore alternate ways to deliver identical functionality. This would be a great stimulus to development of the language. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
CDHWilli@exua.exeter.ac.uk (Charles Williams) (05/14/91)
>mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes > The current standard has two categories of constructs: "general" >and "deprecated". (I'm not sure what terminology the standard actually >uses. I trust my usage is clear enough. The second class corresponds >to old language features retained only for compatibility and which may be >removed in the next round of standardization, while the first category... I seem to recall noting that the Standard is sufficiently broad-minded not only to introduce new feature(s?) and deprecate them straight away.
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (05/15/91)
In article <1991May12.190710.9294@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >In article <16101@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: >> Could we not agree to add to Fortran every 5 years or so those >>new constructs which have proven to be valuable, discuss those directions >>that might be desirable to explore next, but to only standardize on that >>which was proven? > > I think this is an interesting idea. I hope Irving doesn't mind if >I expand on it a bit. > The current standard has two categories of constructs: "general" >and "deprecated". (I'm not sure what terminology the standard actually >uses. I trust my usage is clear enough. The second class corresponds >to old language features retained only for compatibility and which may be >removed in the next round of standardization, while the first category refers to >everything else.) Perhaps the next round should have three classes: >"general", "deprecated" and "exploratory". Implementation of exploratory >features would be encouraged, but not required. We could throw into >this new category anything we're not sure about but would like to try. >We could probably agree on exploratory features faster than we could >agree on general features since they wouldn't be perceived to be cast in >stone. Exploratory features would also allow vendors who thought that the >particular version espoused by the standard was somehow wrong >(inefficient, or whatever) to explore alternate ways to deliver >identical functionality. This would be a great stimulus to development >of the language. > > Marc R. Roussel > mroussel@alchemy.chem.utoronto.ca Please! The quest for the current "standard" was already plagued with enough "exploratory" ideas under the guise of "standardizing existing practice". There is enough work for a standards committee already without adding the tasks of compiler design and R&D. There _should_ be a suitable forum somewhere for exploring new directions, but it isn't the standards committee. They will be lucky if there is even a wide enough base of understanding of the effects of the new features by the time the next round is underway. I like the 5-year idea, if only because it might tend to limit the scope of work to a reasonable amount. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------
wsb@boise.Eng.Sun.COM (Walt Brainerd) (05/16/91)
In article <CDHWILLI.91May13233601@exua.exua.exeter.ac.uk>, CDHWilli@exua.exeter.ac.uk (Charles Williams) writes: > >mroussel@alchemy.chem.utoronto.ca (Marc Roussel) > > writes > > > The current standard has two categories of constructs: "general" > >and "deprecated". (I'm not sure what terminology the standard actually > >uses. I trust my usage is clear enough. The second class corresponds > >to old language features retained only for compatibility and which may be > >removed in the next round of standardization, while the first category... > > I seem to recall noting that the Standard is sufficiently broad-minded > not only to introduce new feature(s?) and deprecate them straight away. One term used in the Fortran 90 standard is "deleted", of which there are NONE (these would be features in Fortran 77, but not in Fortran 90). Note again: there are NONE. The other is "obsolescent", which means there are better ways in Fortran 77 <--- of doing the same thing (in other words, they were obsolete long ago). Of these, only one (alternate return) was new in Fortran 77; none are new in Fortran 90. The others are hot items like the arithmetic IF, the PAUSE statement, the H edit descriptor, etc. These MAY be removed from Fortran 2000 and, if the marketplace dictates, disappear from your compiler in 2030 (not exactly "straight away", even for the alternate return). This corresponds to Roussel's "deprecated". Some of us think that there are new features in Fortran 90 that are _worthy_ of being called obsolete, but there aren't any so labeled. -- Walt Brainerd Sun Microsystems, Inc. walt.brainerd@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
chidsey@smoke.brl.mil (Irving Chidsey) (05/16/91)
In article <RN.1221@mts.ucs.UAlberta.CA> userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: <In article <1991May12.190710.9294@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: <>In article <16101@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: <>> Could we not agree to add to Fortran every 5 years or so those <>>new constructs which have proven to be valuable, discuss those directions <>>that might be desirable to explore next, but to only standardize on that <>>which was proven? <> <> I think this is an interesting idea. I hope Irving doesn't mind if <>I expand on it a bit. I hoped someone would. <> The current standard has two categories of constructs: "general" <>and "deprecated". (I'm not sure what terminology the standard actually <>uses. I trust my usage is clear enough. The second class corresponds <>to old language features retained only for compatibility and which may be <>removed in the next round of standardization, while the first category refers to <>everything else.) Perhaps the next round should have three classes: <>"general", "deprecated" and "exploratory". Implementation of exploratory <>features would be encouraged, but not required. We could throw into Bunch deleted. <> <> Marc R. Roussel < <Please! The quest for the current "standard" was already plagued <with enough "exploratory" ideas under the guise of "standardizing <existing practice". There is enough work for a standards <committee already without adding the tasks of compiler design and <R&D. There _should_ be a suitable forum somewhere for exploring <new directions, but it isn't the standards committee. They will <be lucky if there is even a wide enough base of understanding of <the effects of the new features by the time the next round is <underway. < <I like the 5-year idea, if only because it might tend to limit <the scope of work to a reasonable amount. < < Al Dunbar | I was only throwing out a subject for discussion. This is a fine forum. Irv -- I do not have signature authority. I am not authorized to sign anything. I am not authorized to commit the BRL, the DA, the DOD, or the US Government to anything, not even by implication. They do not tell me what their policy is. They may not have one. Irving L. Chidsey <chidsey@brl.mil>
psmith@convex.com (Presley Smith) (05/16/91)
In article <13372@exodus.Eng.Sun.COM> wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: > >Some of us think that there are new features in Fortran 90 that are _worthy_ >of being called obsolete, but there aren't any so labeled. It's seldom that I agree fully with Walt, but this is one of those times. There are many of us that think there are features that were added to Fortran 90 that should be obsoleted... and probably will be obsoleted after users discover how they really work. I'd also bet that Walt and I have no intersection between our lists of what new features should be obsoleted... It was just too good a line Walt... I couldn't resist a reply... :-)
jlg@cochiti.lanl.gov (Jim Giles) (05/16/91)
In article <13372@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: |> [...] |> The other is "obsolescent", which means there are better ways in Fortran 77 <--- |> of doing the same thing (in other words, they were obsolete long ago). Of |> these, only one (alternate return) was new in Fortran 77; none are new in |> Fortran 90. The others are hot items like the arithmetic IF, the PAUSE |> statement, the H edit descriptor, etc. [...] The nine obsolescent features are: 1) Arithmetic IF Agreed. Should be removed. The IOSTAT returns from the standard IO calls should be specific conditions and not negative-zero-positive. What does one have to do with the other? Why tag a feature as obsolescent and then define an appropriate use for it? 2) Real and Double precision DO control variables. Agreed. There must have been a strong lobby from some vendor to get these into the standard to begin with. 3) Shared DO termination and termination on a statement other than END DO or CONTINUE. Well? Shared termination is useful for short loops which contain initialization of multidimensional arrays. The whole array syntax should do this even more clearly and succinctly. Otherwise, I agree. 4) Branching to an END IF statement from outside its block. I always wondered why END IF could be labeled at all. The same thing goes for END SELECT, END DO, and any other block delimiter that can presently be labeled. 5) Alternate return. Now here's trouble. There are two common ways to implement the alternate return capability: the good way and the bad way. The substitute which the Fortran 90 document recommends is the bad way. Consider the example given in the document: CALL SUBR_NAME (X, Y, Z, *100, *200, *300) They recommend replacing this with: CALL SUBR_NAME (X, Y, Z, RETURN_CODE) SELECT CASE (RETURN_CODE) CASE (1) ... CASE (2) ... CASE (3) ... CASE DEFAULT ... END SELECT The major use of alternate return is as a weak kind of exception handling mechanism. 99.99% of all calls (in most people's code) will _NOT_ raise an exception. But the 'recommended' method here is to test after return each time. The subroutine has already made that test (or it couldn't have set the return code), why should the calling routine repeat that work? Further, I've seen (and written) codes in which nearly every procedure called would have to be followed by this long list of tests - this is called _clutter_. A better way to implement alternate return is to have the called routine substitute the return address in the call chain and then execute a normal return. A better way to do this whole thing is to have a full fledged exception handling capability (implemented internally in the way I've just outlined, but using named exception conditions and block structured syntax to describe the scope of each handler). 6) PAUSE statement. Agreed. It is hard to determine what a PAUSE means in the modern computing environment. From some vendors, the chosen meaning is actually something useful, from others it's not. Most likely it's implemented as an intertactive prompt requiring nothing but a carriage return from the user in response. _Usually_ there is a simpler and more flexible way to do this. 7) ASSIGN statements and assigned GOTO. The recommended substitute is to use INTERNAL procedures. I tend to agree. However, they are the same thing in flow control as pointers are in data structuring - and the committee is just adding pointers. 8) ASSIGN statements with FORMAT labels. It's not clear why they chose to make this a separate issue from point (7). In this case, it is clear that CHARACTER variables (and POINTERs to such) are exact replacements semantically - just a different syntax. I have never needed to do this, but those who do can get by without the ASSIGN just fine. 9) H edit descriptors. I disagree here. The proposed standard claims this edit descriptor can be a source of error. So can all others. The issue here is that people can miscount the number of characters in a string and the H descriptor requires an accurate count. The obverse sode of the coin is that the user often needs to know the number of characters in an output FORMAT when planning the page arrangement. The H edit descriptor (by requiring an accurate count) is a built-in reminder to the programmer - so s/he doesn't have to count again when planning alterations. I suppose this is a minor point, but so is the complaint that the proposal cites as the reason for removing the feature - I don't know anyone who's made this error very often - I know of none in which the compiler didn't promptly catch the error (it _IS_ possible to miss if the character string contains text which could be mistaken for FORMAT descriptors, I've just never seen this happen in a real code). Well, that's the list. I suppose that my basic agreement with 7 out of 9 is fairly reasonable. If my agreement with the features being _added_ to the language were to the same degree, I would feel better about the proposal. As can be seen, it takes considerable effort the eliminate features from a language once they've been introduced. Since I think that a _lot_ of the new features will soon find their way to an obsolescent features list, it would be more economical just to leave them out to begin with. J. Giles
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (05/17/91)
In article <RN.1221@mts.ucs.UAlberta.CA> userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: >In article <1991May12.190710.9294@alchemy.chem.utoronto.ca>, >mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >> The current standard has two categories of constructs: "general" >>and "deprecated". >>Perhaps the next round should have three classes: >>"general", "deprecated" and "exploratory". > >Please! The quest for the current "standard" was already plagued >with enough "exploratory" ideas under the guise of "standardizing >existing practice". That was (more or less) my point. If we moved new and untried features out of the main body of the standard and into an appendix, we could both standardize existing practice and suggest new directions for language development. Currently, the only way to do this is to stick everything into the standard, leading to the difficult process we have just witnessed. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
ravi@earth.ce.nwu.edu (Ravi Sinha) (05/17/91)
In article <23881@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >2) Real and Double precision DO control variables. > > Agreed. There must have been a strong lobby from some vendor to get > these into the standard to begin with. Since I don't know much about how do loops are optimized, maybe someone can cast some light on this. Real DO control variables allow you to have loops like: DO r = 1,100000,0.1 ... ENDDO The replacement with integer DO control variable would be: rbegin = 1 rint = 0.1 DO i=1,1000000 r = rbegin + (i-1)*rint ... ENDDO Maybe someone can tell me why the second form is better from an optimization point of view, and why the first form should be disallowed. Ravi Sinha | <standard disclaimers here> Northwestern University | <cute quote here> ravi@earth.ce.nwu.edu | <cute quote continued here>
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (05/17/91)
In article <23881@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >9) H edit descriptors. > I disagree here. The proposed standard claims this edit descriptor can > be a source of error. So can all others. The issue here is that people > can miscount the number of characters in a string and the H descriptor > requires an accurate count... Just a coding tidbit which allows an accurate count but avoids Hollerith, for those inclined to do so. I started using the following technique a few years ago, and like it a lot. Suppose you wish to provide headers for a set of columns each row of which will be printed by a statement that looks something like this: WRITE( 6, '(x,2f8.3,3x,i4)' ) val1(i), val2(i), i(i) I would print the header in the follwing manner: WRITE( 6, '(x,2a8,3x,a4)' ) 'val1', 'val2', 'i' What I like about it is that to get your header format, you just copy the format statement you're going to use for your numeric output, changing each numeric field to a character field of the same width. This ensures proper lining up of the headers. (Of course, this works just as well with numbered FORMAT statements.) -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
jkorpela@vipunen.hut.fi (Jukka Korpela) (05/17/91)
You stated that Real DO control variables allow you to have loops like: DO r = 1,100000,0.1 ... ENDDO and asked why it should be disallowed and why a DO loop which uses an integer control variable is better from an optimization point of view. I think (I hope!) the reason for disallowing it (or calling it obsolescent) is not optimization, although it seems intuitively clear that it is usually easier to optimize a loop with an integer control variable. The point is that using a real control variable leads to INACCURACIES. A value such as 0.1 is not reprented exactly on most computers. The inaccuracy is small but it is ACCUMULATED. Thus the values for which the loop is actually executed differ from what you probably expect. Moreover, the number of executions is very often off-by-one; if you have DO r=1,100000,0.1, the last value of r for which the loop is executed might be about 99999.9, since after adding 0.1 to it the result might be more than 100000 due to inaccuracies.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/17/91)
In article <23881@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: > 8) ASSIGN statements with FORMAT labels. > > It's not clear why they chose to make this a separate issue from point > (7). In this case, it is clear that CHARACTER variables (and POINTERs > to such) are exact replacements semantically - just a different syntax. > I have never needed to do this, but those who do can get by without the > ASSIGN just fine. I have two observations to make about this. The first is that I was rather surprised, looking at a supersonic flow code written *recently*, to see that it was full of ASSIGNs. It turned out that they were all "ASSIGN statements with FORMAT labels". The second is that CHARACTER variables are _not_ exact replacements, although a smart Fortran compiler _could_ notice this special case. What's the difference? Well, a compiler can _check_ a FORMAT statement at compile time, and can even generate code for it. Using ASSIGN with FORMAT labels ensures that you are _not_ passing to READ or WRITE any formats that the compiler hasn't had a chance to look at. This _can_ buy you safety (compile-time check) and speed (the format being compiled, not interpreted at run time). Now, a Fortran compiler should be keeping around use/def information, so that when it says CHRVAR='(...)' it could say "hmm, it's guaranteed that the next use of this variable is as the format argument of an I/O statement, so I'll check now that the literal is a valid format, and I'll even generate code for it." This is what the C people call "a quality-of-implementation issue". It _can_ be done, and it shouldn't even be hard, but _will_ it be done? -- There is no such thing as a balanced ecology; ecosystems are chaotic.
jlg@cochiti.lanl.gov (Jim Giles) (05/17/91)
In article <5807@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: |> In article <23881@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: |> > 8) ASSIGN statements with FORMAT labels. |> > [...]In this case, it is clear that CHARACTER variables (and POINTERs |> > to such) are exact replacements semantically - just a different syntax. |> [...] |> The second is that CHARACTER variables are _not_ exact replacements, |> although a smart Fortran compiler _could_ notice this special case. |> [...] I should have been more clear. When I say that something is the same semantically, I am claiming that the _meaning_ of a correct program is the same. Operationally, there may be differences of efficiency which I am not referring to. J. Giles
jlg@cochiti.lanl.gov (Jim Giles) (05/17/91)
In article <1991May16.195414.25217@cunixf.cc.columbia.edu>, shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: |> In article <23881@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: |> >9) H edit descriptors. |> > I disagree here. [...] |> |> What I like about it is that to get your header format, you just copy the |> format statement you're going to use for your numeric output, changing each |> numeric field to a character field of the same width. [...] Your idea was interesting and perfectly useful. I would point out however that column headers are not the only context where the character count of a literal string is useful. Still, there's no denying that your method has a lot going for it. Walt Brainerd should publish your idea as a letter to the Fortran Journal. J. Giles
jlg@cochiti.lanl.gov (Jim Giles) (05/17/91)
In article <1991May16.195328.727@casbah.acns.nwu.edu>, ravi@earth.ce.nwu.edu (Ravi Sinha) writes: |> [...] |> Real DO control variables allow you to have loops like: |> DO r = 1,100000,0.1 |> ... |> ENDDO |> |> The replacement with integer DO control variable would be: |> rbegin = 1 |> rint = 0.1 |> DO i=1,1000000 |> r = rbegin + (i-1)*rint |> ... |> ENDDO |> |> Maybe someone can tell me why the second form is better from an |> optimization point of view, and why the first form should be disallowed. The problem is not optimization but accurate trip count calculation. The loop trip count is calculated as follows: trip_count = INT((end - start + stride) / stride) In your first loop, you're going to get the following calculation: trip_count = INT(99999.1/0.1) Since floating point calculations are inexact, the above may give either 999991 or 999990 depending on rounding before the explicit integer truncation. It doesn't matter what the floating point format is nor what the rounding mode is, you can always find a case which produces the wrong answer. Since integer arithmetic must be exact (as long as it's in range), this problem doesn't arise. Note: your integer loop takes too many steps. It corresponds to a float loop which goes from 0.1 to 100000.0 instead of 1 to 100000 by 0.1. Needless to say (but I will anyway), the calculation of INT(1000000/1) is exact. So would the calculation of DO i=1,999991 => INT(999991/1) which would be a correct expression of you first loop. Of course, the above confusion reveals the difficulty with removing float DO loop limits - converting back to integer limits is error prone. J. Giles
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (05/18/91)
In article <1991May16.195328.727@casbah.acns.nwu.edu> ravi@earth.ce.nwu.edu (Ravi Sinha) writes:
Real DO control variables allow you to have loops like:
DO r = 1,100000,0.1
...
ENDDO
The replacement with integer DO control variable would be:
rbegin = 1
rint = 0.1
DO i=1,1000000
r = rbegin + (i-1)*rint
...
ENDDO
Maybe someone can tell me why the second form is better from an
optimization point of view, and why the first form should be disallowed.
Try your codelet on a variety of machines (with radically different
fp; say IBM S/360 family, VAX, IEEE, Univac, old Cyber, new Cyber).
You will probably be surprised at what you get on some machines ....
yet all of them will be working just fine ....
Using fp for loop control is dangerous; you can't trivially predict
how many times a loop will be executed (for extra points, construct an
example where ieee gradual underflow causes your loop to get executed
tons of times more than you expected).
--
----------------------------------------------------------------
Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043CDHWilli@exua.exeter.ac.uk (Charles Williams) (05/19/91)
>ravi@earth.ce.nwu.edu (Ravi Sinha) <1991May16.195328.727@casbah.acns.nwu.edu> > >Real DO control variables allow you to have loops like: > DO r = 1,100000,0.1 > ... > ENDDO > >The replacement with integer DO control variable would be: > rbegin = 1 > rint = 0.1 > DO i=1,1000000 > r = rbegin + (i-1)*rint > ... > ENDDO > >Maybe someone can tell me why the second form is better from an >optimization point of view, and why the first form should be disallowed. You've picked an interesting example because machines use binary/hex representations of real numbers and have no exact real representation for the number 0.1 This means that the number of times an optimised loop of this type is executed is not always the same as the unoptimised version, especially if you are using the facilities of ieee arithmetic to adjust the FPU behaviour at run time... Some F77 compilers squeal if you even try to compare two reals for equality or inequality. IMHO even if the precise behaviour of reals *is* defined somewhere it's easier to use integer for do-looping and avoid having to wonder about the portability/optimisation/ieee settings/termination issues that the reals involve...er, flame-suit on... My news reader wants more lines here
buckland@ucs.ubc.ca (Tony Buckland) (05/21/91)
In article <JKORPELA.91May17111428@vipunen.hut.fi> jkorpela@vipunen.hut.fi (Jukka Korpela) writes: >The point is that using a real control variable leads to INACCURACIES. >A value such as 0.1 is not reprented exactly on most computers. The >inaccuracy is small but it is ACCUMULATED. Thus the values for which >the loop is actually executed differ from what you probably expect. Several posters have pointed this out. But surely they realize that long-time FORTRAN programmers _know_ about inexact representation of floating-point quantities. They also know that they will, if they use enough decimal places, get results which are good enough. If, to use one poster's example, they want to label plots, they will get good labels to three places if they add an increment vague only in the seventh place. Slide rules were inexact, too. But we still let one another use them; similarly, we should let one another go on applying FORTRAN 77's admirable principle of allowing use of any type which makes sense in the context, one of these contexts being DO control statements.
ravi@earth.ce.nwu.edu (Ravi Sinha) (05/21/91)
>>The point is that using a real control variable leads to INACCURACIES. >>A value such as 0.1 is not reprented exactly on most computers. The >>inaccuracy is small but it is ACCUMULATED. Thus the values for which >>the loop is actually executed differ from what you probably expect. > > Slide rules were inexact, too. But we still let one another > use them; similarly, we should let one another go on applying > FORTRAN 77's admirable principle of allowing use of any type > which makes sense in the context, one of these contexts being > DO control statements. I was the original poster with the abominable example where the DO loop increment value was 0.1. Several people have noted, both here and through email that integer DO loop control variable is better for this example where round-off would cause error in the number of times the loop is evaluated. Well, it was a BAD example and almost everyone missed the point... The point is: If you allow a language to have a feature which can be used very intuitively, should you remove the feature later on? If we are dealing with real variables, real DO loop control variables *are* the most intuitive choice. So, do you want to leave the onus of being correct on the compiler writers, or on the end users? How about requiring that all real DO control variables should be evaluated in extended precision (R*16), and the result passed back in REAL or DOUBLE as the case may be. Would this take care of roundoff errors in all cases? And how does the overhead compare with using integer DO variables and calculating the REAL variable from it? To make peace with those who have considered me to be sigularly incompetent: Through years of habit, I never use real DO variables. This is why it didn't occur to me that increment size of 0.1 is not a very good choice for this example. Ravi Sinha | <standard disclaimers here> Northwestern University | <cute quote here> ravi@earth.ce.nwu.edu | <cute quote continued here>
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/21/91)
In article <1991May20.182514.17651@casbah.acns.nwu.edu>, ravi@earth.ce.nwu.edu (Ravi Sinha) writes: > The point is: > If you allow a language to have a feature which can be used very > intuitively, should you remove the feature later on? If we are > dealing with real variables, real DO loop control variables *are* > the most intuitive choice. There are two observations to make about this. (1) It may be "intuitive", but it is almost always WRONG. Any use of DO loops with fractional increments is going to give you serious porting problems _unless_ you have worked out so very carefully the consequences of roundoff for this particular loop that it is no longer relevant whether the result is "intuitive" or not. (2) There _is_ a legitimate use for real-valued DO loops on some machines. With IEEE arithmetic, you can represent 53-bit INTEGERS as doubles, and integer operations on those values are correct. Any machine whose floating-point operations can be shoe-horned into Brown's model has _some_ range of integral values which can be correctly represented as floats and operated on using floating- point arithmetic. So there can be loops whose end-points are not representable as Fortran INTEGERs, but where the number of iterations is reasonable, and a loop using DOUBLE can work just fine. However, such loops are anything but portable. The range of integral values correctly handled by DOUBLE arithmetic is highly machine-dependent (as for that matter is the range of integral values correctly handled by INTEGER arithmetic). > So, do you want to leave the onus of > being correct on the compiler writers, or on the end users? The onus remains where it always has been. Compiler writers are responsible for correct compilers. Program writers are responsible for correct programs. For non-integral loops, the *only* person/people who has/have the information required to demonstrate that such a loop is correct is/are the programmers, _not_ the compiler writers. > How about requiring that all real DO control variables should be > evaluated in extended precision (R*16), and the result passed back in > REAL or DOUBLE as the case may be. Would this take care of roundoff > errors in all cases? Of *course* it wouldn't! IEEE "extended precision" numbers are 80 bits long (REAL*10, as it were). Why should a Fortran system be obliged to include a software implementation of 128-bit arithmetic just so people can write DO loops without thinking about what they are doing? > And how does the overhead compare with using integer DO variables > and calculating the REAL variable from it? Except on machines having 128-bit hardware, the integer approach is *MUCH* cheaper. As for the example concerning tick marks on a scale; it's a funny thing, but I've seen several statistics packages written in Fortran, and there are several algorithms published in the literature, and do you know, using a safe (integer) loop really isn't that hard. It would not have been advantageous to those programs. > To make peace with those who have considered me to be sigularly > incompetent: Through years of habit, I never use real DO variables. > This is why it didn't occur to me that increment size of 0.1 is > not a very good choice for this example. That fact that it didn't occur to someone who is confident of his competents is a good indication that it is a risky construct, no? -- There is no such thing as a balanced ecology; ecosystems are chaotic.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/21/91)
In article <1991May21.113540.783@csc.canterbury.ac.nz>, phys169@csc.canterbury.ac.nz writes: > Suppose there was a new "standard" every 11 years (say, and change the name of > Fortran 90 to Fortran 88 for neatness! :-), but a convention amongst compiler > writers and users about twice as often, so significant worthwhile ideas could > be discussed and organised - not quite to the point of standardisation - years > before Fortan 99 (or whatever). You have to remember that the present Fortran 90 was arrived at in very much this manner. To quote the Bible, "this thing was not done in a corner". The fact that work on Fortran 8X was proceeding was well publicised; anyone who wanted to find out what was being considered would only have had to go to a library and scan through a couple of ACM publications (for example) to find out who to write to. I saw a draft of 8X back in '87, and that was in a Prolog company! Any Fortran compiler writer who is taken by surprise with Fortran 90 simply hasn't been paying attention. -- There is no such thing as a balanced ecology; ecosystems are chaotic.
paco@rice.edu (Paul Havlak) (05/21/91)
The biggest problem with real-valued DO-variables is that they don't really exist. Offering them as part of the syntax is confusing to users of the language. Iteration, like subscripting, is an integer concept. One cannot enter a DO-loop a fractional number of times, any more than one can reference a fractional element of an array. The standard requires subscript expressions to be integer. Unfortunately, it is more cryptic about the processing of DO-loops. In essence, the standard requires that real-valued DO-variables be shadowed with an integer-valued iteration count. This can have the confusing effect of terminating a DO-loop while the DO-variable is still in range. ANSI X3.9-1978 FORTRAN 77, page 11-7 defines the execution of a a DO-loop as follows (taking minimal expository liberties): DO <label> <DO-variable> = <init>, <term> [, <inc>] ... / DO- \ <label> ... \ range / Let T be the type of the DO-variable. On execution of the DO-header, evaluate the expressions and convert them to type T: INIT = T(<init>) TERM = T(<term>) INC = T(<inc>) Assign the iteration count to be MAX( INT( (<term> - <init> + <inc>)/<inc>), 0) Assign the DO-variable <DO-variable> = INIT Loop-control processing executes the DO-range if the iteration count is not zero. Each time that the normal end of the DO-range is reached, incrementation processing * decrements the iteration count by one * increments the DO-variable by INC * continues execution with loop-control processing In other words, the real-valued DO-variable is just a sideshow. Even worse, because the computation of the DO-variable and the iteration count are required to be independent, implementations are forced by the standard and the realities of floating-point to allow them to get out of sync (e.g., if the increment is small enough relative to the bounds). Gedankenexperiment: What happens if the bounds and increment are such that adding INC to INIT has no effect, but the iteration count can still be evaluated as an integer?
phys169@csc.canterbury.ac.nz (05/21/91)
In article <RN.1221@mts.ucs.UAlberta.CA>, userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: > In article <1991May12.190710.9294@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >>In article <16101@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: >>> Could we not agree to add to Fortran every 5 years or so those >>>new constructs which have proven to be valuable, discuss those directions >>>that might be desirable to explore next, but to only standardize on that >>>which was proven? >>... >>"general", "deprecated" and "exploratory". Implementation of exploratory >>features would be encouraged, but not required. We could throw into >>this new category anything we're not sure about but would like to try. > > Please! The quest for the current "standard" was already plagued > with enough "exploratory" ideas... > I like the 5-year idea, if only because it might tend to limit > the scope of work to a reasonable amount. > Suppose there was a new "standard" every 11 years (say, and change the name of Fortran 90 to Fortran 88 for neatness! :-), but a convention amongst compiler writers and users about twice as often, so significant worthwhile ideas could be discussed and organised - not quite to the point of standardisation - years before Fortan 99 (or whatever). Then the job of taking existing features and munging them into a standard would be easier (because the main ones would have been partially standardised at least among compiler producers), and the general Fortran community would have had plenty of time to debate their worth beforehand. So... 1 a new Fortan "N" comes out 2 compiler writers produce something that can handle N (and probably N-11) 3 in year (N+4) people discuss new features and try to agree on syntax & naming, so if two compilers add a feature your programs can run on both; these additions to the standard (which mustn't upset compiling Fortran N) are called the Fortran N+4 "convention", not a standard, and compilers that claim to follow the convention need not have all new features, but those they do have should conform. Compilers with other extensions can't claim to follow the convention, so people will be reluctant to use them, so one large company adding significant features (that would otherwise be something the standards guys have to later thrash out) would be rare. 4 New features that came along in N+4 and perhaps N+8 would be considered for going into the Fortran N+11 standard. The job would be easier and the discussion process, as well as the compiler-writing processes, would be much faster. 5 N=N+11 6 goto 1 (Just my two cents worth) Mark Aitchison, Physics, University of Canterbury, New Zealand.
vsnyder@jato.jpl.nasa.gov (Van Snyder) (05/22/91)
I tried for several years to get X3J3 to extend CASE to include REAL ranges.
I explained carefully that this was nothing different from IF...ELSE IF ...
ELSE IF ... ELSE ... END IF, but that the part of the predicate repeated in
each ELSE IF was put into the SELECT CASE statement instead. All I got
by way of explanation for failure to extend CASE was that:
1. "Real relationals were a mistake in Fortran 77 that we didn't want to
repeat."
2. "Real induction variables in DO in Fortran 77 were a mistake that we
didn't want to repeat."
3. "Real subscripts ... "
4. "There will be non-portable round-off problems."
5. "There WILL be non-portable round-off problems."
Nobody explained any of these. How can allowing a programmer to write
a clearer, more optimized version of IF ... ELSE IF ... ELSE IF ... ELSE
block cause any of the above problems?
BTW, the attraction of Arithmetic IF is that it does a little bit of what
extending CASE to REAL ranges would allow. The alternative to
IF (e) 10,20,30
SHOULD have been
SELECT CASE e
CASE * < 0
blah blah (statement 10ff above)
CASE * = 0
blah blah (statement 20ff above)
CASE * > 0 ! or DEFAULT
blah blah (statement 30ff above)
END CASE
instead of
IF (e.lt.0) THEN
blah blah 10
ELSE IF (e.eq.0) THEN
blah blah 20
ELSE
blah blah 30
END IF
which requires "e" to be evaluated twice, or the almost as repulsive
temp = e
IF (temp.lt.0) THEN
...
Where does the non-portable round-off creep in? That is, the non-portable
round-off in CASE that's different from the non-portable round-off in the
equivalent sequence of IF ... ELSE IF ...
--
vsnyder@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsnyder@jato.uucp