50 years of progress in the language
Terence
I've been converting a set of old Fortran IV (mainly) programs, to
versions "more understandable" (to me at least).
To be fair, almost every program would compile and run correctly using
an F77 compiler
but the code contained:-
Hollerith (nH-type) text strings for output and comunicating
ASSIGN label TO i structures and associated use thereof:
GO TO i,(L1,L2,L3,,)
All alphabetic text constants were equated to double precision
floats,
Smaller length (1-4) alphabetic test onstant strings were treated as
reals,
All condtional branches used three-way arithmetic IF statements,
There were no logical IF statements,
Almost every do loop shared nested labels where possible
All matrices had the index of faster sequential progress in memory
at the right and not at the left
Conversion between integer variabless and equivalent digit strings
was
done by writing a scratch tape and reading back with another
format.
Every subroutine name shared among the 56 programs had very
different
code associated with the names; some with more, some with fewer
options and error handling, even if the purpose was very similar..
I was extremely surprised at how much work appeared to be necessary to
eliminate the obsolescent code and the enormous complexities of
testing for, and manipulating
characters in any way.
Most I solved (reported) by writing a program to automate much of the
conversion:
indent nests of DO loops for readability; supply a CONTINUE ending to
DO-loops where possible; convert hollerith to apostophe-delimited
strings;
providing sequential re-labeling; note unused labels; report ASIIGN
use.
But comparing the task of programming, between 'then', and now, there
were two
additions to the language that have helped enormously
1) the internal read.
2) the character array and the character string.
The next, in my opinion, would be the IF-THEN-ELSE structrues.
After which point I haven't seen any real advantage to further bells
and whistles.
So 1956 to 1976 was a good 20 years of progress, but the next 30 have
been like new
verisions of any of the "old", first "X" software versions: noow
larger, more complicated, more expensive, larger boxes, but all to do
the same basic job.
It's just a personal refection on my last three months of work, with
the first three in this field, nearly 50 years ago
nm...@cam.ac.uk
Terence <tbwr...@cantv.net> wrote:
>
>But comparing the task of programming, between 'then', and now, there
>were two
>additions to the language that have helped enormously
>1) the internal read.
>2) the character array and the character string.
>
>The next, in my opinion, would be the IF-THEN-ELSE structrues.
>
>After which point I haven't seen any real advantage to further bells
>and whistles.
>So 1956 to 1976 was a good 20 years of progress, but the next 30 have
>been like new
>verisions of any of the "old", first "X" software versions: noow
>larger, more complicated, more expensive, larger boxes, but all to do
>the same basic job.
If you have been thinking in entirely Fortran 66 terms, that is not
surprising; with almost all language advances, you don't see most of
the benefits until you start thinking in the more advanced terms.
However, here is a revision (and simplification, true) of LAPACK
routine SPOTRF - I suggest that you look at it and the original.
MODULE double
INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND(12)
END MODULE double
SUBROUTINE CHOLESKY(A)
USE double
IMPLICIT NONE
INTEGER :: J, N
REAL(KIND=dp) :: A(:, :), X
N = UBOUND(A,1)
DO J = 1, N
X = SQRT(A(J,J)-DOT_PRODUCT(A(J, :J-1), A(J, :J-1)))
A(J,J) = X
IF (J < N) &
A(J+1:, J) = (A(J+1:, J) - &
MATMUL(A(J+1:, :J-1), A(J,: J-1))) / X
ENDDO
END SUBROUTINE CHOLESKY
I point out that this is a direct transliteration of the mathematics
that the students see in books and papers, and that makes it a LOT
easier and less error prone to convert such mathematics to code.
Regards,
Nick Maclaren.
Les Neilson
arrays, and modules; though there are probably other modern facilities in
the language that I have used "without thinking about it".
Les
Terence
Oh! I DO program in F90 when native windows mode is needed (very
rarely).
And I output F77-coded reports in RTF which gets around a LOT of
problems
.
And I agree the allocatable storage looks useful, but I never have
needed it because I use named common; and this has the advantage that
the same named common goes with any subroutine that needs that
interface. And if an array is over 64K I use disk.
I use F77 mode and compilers, not F66. And both MS F77 and DVF 6,6c
compilers, libraries and output executables all run on every Windows
computer I have (95,98,NT, 2000, XP) plus the Macintosh in MS
emulation mode. I didn't fully try W3.1 but the F77 compile ran on
that one too
And my own general text interfaces (DOS and Windows version libraries)
mean no reliance on third-party software.
I wrote and rewrote a subset of these 56 programs, (using a software
copy/compare trick) each time adding more structure, ending with FAR
less code by adding two really major INCLUDEs (one data structures as
mentioned, the other file handling start-up, and user interfaces).
After a point, this method fitted all programs from there on. And the
total of code, includes, and general subroutines, and the total size
of the executables, are both far less in size than the same totals for
the originals that run as-is. But I found some weird errors in the
originals while testing., and some unused code here and there.
user1
>
> And if an array is over 64K I use disk.
>
>
Sounds like a retro 16-bit compiler hack. Those days are over, at least
for most people.
Arjen Markus
> I've been converting a set of old Fortran IV (mainly) programs, to
> versions "more understandable" (to me at least).
>
> But comparing the task of programming, between 'then', and now, there
> were two
> additions to the language that have helped enormously
> 1) the internal read.
> 2) the character array and the character string.
>
> The next, in my opinion, would be the IF-THEN-ELSE structrues.
>
> After which point I haven't seen any real advantage to further bells
> and whistles.
> So 1956 to 1976 was a good 20 years of progress, but the next 30 have
> been like new
> verisions of any of the "old", first "X" software versions: noow
> larger, more complicated, more expensive, larger boxes, but all to do
> the same basic job.
>
> It's just a personal refection on my last three months of work, with
> the first three in this field, nearly 50 years ago
For me (my first substantial experience dates from the FORTRAN 77 era
with some exposure to FORTRAN IV) one of the great advantages of
Fortran 90/95
is the ease by which you can force the compiler to check the
syntactically
correct use of routines (arguments of the correct type).
And of course memory management.
And quite a few other tidbits :).
Regards,
Arjen
dpb
...
> ... two additions to the language that have helped enormously
> 1) the internal read.
> 2) the character array and the character string.
>
> The next, in my opinion, would be the IF-THEN-ELSE structrues.
>
> After which point I haven't seen any real advantage to further bells
> and whistles.
> It's just a personal refection on my last three months of work, with
> the first three in this field, nearly 50 years ago
While responding is undoubtedly futile as your opinions are well known
and established, I think your thinking and approach has remained
essentially the same in that period of time as well.
As only one example, advantages of modules for automagic generation and
checking of interfaces is undoubtedly a great timesaver for debugging
and generation of correct, more robust code.
But, your above list of programming technique of using COMMON for
interfacing routines effectively neuters the compiler from making any
use of the feature. Hence, obviously you don't see the benefit.
But, to draw the conclusion the feature isn't useful in general thereby
is simply making an error in deduction.
--
Bil Kleb
> After which point I haven't seen any real advantage to further bells
> and whistles.
Along these lines, Jay Field's latest blog entry "Kill your Darlings",
http://blog.jayfields.com/2009/03/kill-your-darlings.html
suggests killing a language after it reaches the third version.
Regards,
--
http://twitter.com/bil_kleb
Terence
It's not entirely what you refer to as "my views" that drive my
comments, but the fact that the greater part of my faithful clients
are in third world countries where the AT and 386 still reign supreme.
And they use external data-capture hardware with RS232c plugs and not
a sign of a USB port anywhere - so they use what they can. And economy
was very important and now an imperitive.
That's why I still have W95, W98, NT, W2000 and XP computers to test
on.
This preferred use of F77 allows me to produce software where the same
executable runs on DOS, OS-DOS, Windows command-line and MACs with the
MS emulator.
For the true Window fan, I supply a real native Windows F95 Menu
program that then proceeds to call DOS executables and DOS general
sort-merge programs or user-anything programs. Since any report output
is RTF-coded, you can then apply all the cut-and past you want
(although that feature and windowing is also in the DOS user
interfaces).
Note that the MS F77 compiler has a cross-reference feature and lists
variable names by types and subprogram; which covers one objection
raised.
But with small compacted code, I can e-mail new programs and updates
'en masse' to people who often use a telephone line to receive e-mail.
Another point, (which reminds me of my days as an English physicist
'string and sealing wax' experiments versus the megabuck USA ones.
Remember Crick and Watson's laboratory flask holders and stands, and
cardboard cut-outs to deduce DNA structures? And in 1958 I was
designing electon electrostatic lenses with a copper-covered wooden
model in a tank of water and a resistence meter):-
Many years ago the Russians had a mass-produced AT-clone as the only
publicly available computer (purchased IBM mainframes were installed
in places like Turkey and then... moved). But what great code they
produced! Efficient as possible! Bulgarians were also pretty good
too.
The American was the opposite: 'whatever the size of computer
available, it will be filled'. Just because the F77 compiler is 'old'
it doesn't mean it's not efficient and both source code and the
compiled code are very transportable.
Terence
Yes, I read it. But I don't 'keep my code'. The external rules of use
(syntax of interface) remain the same; (in many cases they are an
international standard) but every three to six months I re-write
between a great part and all of a particular program, because either I
see how additional options make something more general or more
valuable, or I see how another competitor input or format can be
introduced. My work is in statistics; the rules don't change, only the
application of the code to different file systems and new value
notations and new graphic interfaces.
dpb
...
> It's not entirely what you refer to as "my views" that drive my
> comments, but the fact that the greater part of my faithful clients
> are in third world countries where the AT and 386 still reign supreme.
> This preferred use of F77 allows me to produce software where the same
> executable runs on DOS, OS-DOS, Windows command-line and MACs with the
> MS emulator.
That's a valid reason, but has nothing to do w/ the comments (dare I say
aspersions?) against the advances in the Fortran language claiming no
benefits in the new features.
...
> ... Just because the F77 compiler is 'old'
> it doesn't mean it's not efficient and both source code and the
> compiled code are very transportable.
There's nothing per se limiting in the F95 compiler that prevents it
also from generating compact and efficient code for a 16-bit system,
assuming there were enough of a market that vendors found it useful to
do so. I don't doubt it could even be done that a DOS-executable
compiler could implement the newer Standard features -- OW has quite a
few of F90's altho not all are in a Standard-compatible form.
The major missing pieces are modules but that alone is sufficient imo to
move away from F77-only compilers unless there is another reason such as
you've outlined of needing code for systems for which there are no later
compilers.
But, I'm convinced if there were one, it would still lead to more
productive programming and shorter debugging and more robust code if you
were to use it and the features made available by it.
--
Richard Maine
> Terence wrote:
> ...
> > It's not entirely what you refer to as "my views" that drive my
> > comments, but the fact that the greater part of my faithful clients
> > are in third world countries where the AT and 386 still reign supreme.
> ...
> > This preferred use of F77 allows me to produce software where the same
> > executable runs on DOS, OS-DOS, Windows command-line and MACs with the
> > MS emulator.
>
> That's a valid reason, but has nothing to do w/ the comments (dare I say
> aspersions?) against the advances in the Fortran language claiming no
> benefits in the new features.
The same thoughts had occurred to me, but I mostly avoid bothering to
argue with Terence, as such argument seems a bit pointless to me.
The arguments "that's not available in my environment" and "that's not
worth anything anyway" are pretty distinct. When someone switches freely
between them as though they were the same point, I tend to suspect
rationalizations are dominating objective reasons.
As a completely unrelated aside, "Mac" is an abbreviation for
"Macintosh" rather than an acronym. Thus only the initial letter should
be capitalized. "MAC" is "Media Access Control" or any of several other
acronyms. A Mac can have a MAC address (or several), but then so can a
Windows box.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
dpb
> dpb <no...@non.net> wrote:
...
>> That's a valid reason, but has nothing to do w/ the comments (dare I say
>> aspersions?) against the advances in the Fortran language claiming no
>> benefits in the new features.
>
> The same thoughts had occurred to me, but I mostly avoid bothering to
> argue with Terence, as such argument seems a bit pointless to me.
Yes, I knew (as I noted in the first response) it was pointless, but
somehow still think the point is worth making for the hapless bystander
if nothing else.
But, I will say from what Terence actually outlined in this previous
response that I do understand more of from whence he's coming only that
he does as you say, mix two unrelated concepts. I'd prefer he cease
doing that but that's probably (definitely? :) ) too much to ask...
Anyway, I've said my piece and shall now retire.
--
Terence
I didn't realise I seemed to be "knocking" F90/f95/2003 etc.
I DID spend the money to get DVF F90/F95 (which I like a lot, very
good manual indeed, but the MS Development System environment is a
hinderence to programming with it.
And I built on the Compaq user interface example to build a really
useful tool which matched in module name by module name, the same
kind of interface I use for DOS and Windows command line versions. So
it's just one Fortran source code and two compiled versions
But I lose a lot of time setting options and work spaces and so on
with DVF. And the edit doesn't work properly: 'Find' doesn't, because
it restes the argumant to the character where one stops! And the
editor always wants to go to column 7 and not 1 for the next line. But
the compiler works dso I edit aoutside and cut and paste into the
compile and test environment.
In short, i get far more work done in any time block with F77. And
then and then only is it worth recompiling with DVF; but by then it's
bug free.
I also bought Intel's Fortran V9 in 2007 which somehow I never got
working on my W2000, so I went back to DVF for all Windows work.
dpb
> I appreciate the time taken to comment on my notes.
> I didn't realise I seemed to be "knocking" F90/f95/2003 etc.
Well, when you say language features aren't of any value since F77 I
don't know how else you expect that to be interpreted.
> I DID spend the money to get DVF F90/F95 (which I like a lot, very
> good manual indeed, but the MS Development System environment is a
...
> But I lose a lot of time setting options and work spaces and so on
> with DVF. ...
> In short, i get far more work done in any time block with F77.
...
I'll make little effort to defend the Visual Studio editor, particularly
in its default key mapping--it sucks, granted. _BUT_, again, that has
no bearing whatsoever on Fortran; it's an IDE/code editor.
I use the IDE on occasion, but even when I do I set the editor in an
emulation mode (Brief) so it works as I'm accustomed (sorta', even the
emulation isn't perfect and some things one can't turn off). But, it is
essentially seamless to open any other editor from within that one wants
rather than use the lame MS editor.
But, even beyond that, it's the features of the language itself that add
the benefits that it seems to me you're missing out on by insisting on
staying at the F77 level. But, of course, when you're forced to build
executables for native DOS/16-bit, then I don't know of any compiler
that has that ability that also is F95-compliant.
So, again, in short I think there's a mismatch in the comparison of what
is Fortran and what is the environment under which the compiler is being
used or is wrapped in that is independent of the inherent language features.
--
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>As a completely unrelated aside, "Mac" is an abbreviation for
>"Macintosh" rather than an acronym. Thus only the initial letter should
>be capitalized. "MAC" is "Media Access Control" or any of several other
>acronyms. A Mac can have a MAC address (or several), but then so can a
>Windows box.
Whereas I have a Mac address :-)
Regards,
Nick Maclaren.
Richard Maine
Jinsong Zhao
> ASSIGN label TO i structures and associated use thereof:
> GO TO i,(L1,L2,L3,,)
Is there a convenient way to convert this to a modern form? or tools?
Thanks,
Jinsong
dpb
...
> the compiler works dso I edit aoutside and cut and paste into the
> compile and test environment.
I didn't fully comprehend what you were saying last night...
If you're actually transferring the text from one editor to within the
CVF editor by manual cut 'n paste, you certainly are making a lot of
work. Simply use the editor of choice and save the edits to disk
_in_that_session_ and the IDE will use the updated files.
> In short, i get far more work done in any time block with F77. And
> then and then only is it worth recompiling with DVF; but by then it's
> bug free.
But I'll add it takes some time and effort to learn any new tool and
that goes for both the IDE and the features of F95.
Although I fully understand how one gets into a pattern (or rut?). My
preferred development environment is actually the old DOS Brief editor
w/ using its ability to compile in background and return to the point of
any compilation errors. I've used that particular editor since my first
PC so it has become so much a habit the missing or klunky emulation in
VS doesn't make up for the missing features.
But again, this discussion is about the programming environment, not
Fortran which is what the subject line implies. I think it's
unequivocal there's significant progress there since F77 but you're
complaints/comments really seem to evolve around particular
implementation(s), not the language.
And now, hopefully, I _am_ done... :)
--
JB
> But with small compacted code, I can e-mail new programs and updates
> 'en masse' to people who often use a telephone line to receive e-mail.
Hopefully you don't use big BLOCK DATA blocks or other statically
initialized data structures then, as those tend to go into the .data
section (or whatever the equivalent on dos/windows is) and bloat the
object code.
> Another point, (which reminds me of my days as an English physicist
> 'string and sealing wax' experiments versus the megabuck USA ones.
> Remember Crick and Watson's laboratory flask holders and stands, and
> cardboard cut-outs to deduce DNA structures? And in 1958 I was
> designing electon electrostatic lenses with a copper-covered wooden
> model in a tank of water and a resistence meter):-
And our ancestor evidently survived as hunter-gatherers; shall we all
chuck this modernity nonsense and go back to clubs and spears? Nobody
is disputing that people did amazing things a long time ago with what
we today would consider very primitive means, but gee, perhaps in some
cases there really are better ways nowadays.
> Many years ago the Russians had a mass-produced AT-clone as the only
> publicly available computer (purchased IBM mainframes were installed
> in places like Turkey and then... moved). But what great code they
> produced! Efficient as possible! Bulgarians were also pretty good
> too.
>
> The American was the opposite: 'whatever the size of computer
> available, it will be filled'.
And still those damn Yanks managed to "win" the cold war.
> Just because the F77 compiler is 'old'
> it doesn't mean it's not efficient
Of course it does. For instance, a decades old compiler has little
idea how to optimize specifically for modern processors, and has
missed out on a lot of compiler research and development. Now that may
not as such be a huge deal; there is the saying that Moore's law
doubles the speed every 18 months (yes yes, it's about transistor
density not speed yadda yadda), whereas compiler technology doubles
the speed every 18 years.
More importantly however, a 64 KB size limit on arrays is totally
unacceptable for many, if not an overwhelming majority, of users,
yours truly included. Yes, you could work around it to a limited
extent with segments in real mode x86, or by writing your own disk
swapping routines, but this is orders of magnitude slower than using
memory and hence completely unacceptable for much serious work. Not to
mention tedious; heck virtual memory with a flat address space was
invented ~40 years ago, and most people never looked back once they
got their hands on it, for good reasons.
--
JB
Richard Maine
> More importantly however, a 64 KB size limit on arrays is totally
> unacceptable for many, if not an overwhelming majority, of users,
> yours truly included. Yes, you could work around it to a limited
> extent with segments in real mode x86, or by writing your own disk
> swapping routines, but this is orders of magnitude slower than using
> memory and hence completely unacceptable for much serious work. Not to
> mention tedious; heck virtual memory with a flat address space was
> invented ~40 years ago, and most people never looked back once they
> got their hands on it, for good reasons.
Yep. Been there. Not so much with the exact 64k size limit as a general
need to keep memory usage down to fit on the machines or to be small
enough that my jobs wouldn't have to wait for the overnight queue.
I recall looking at porting one of those programs to a new computer (our
shiny new Elxsi in 1984). I decided that the virtual memory with flat
address space made it worth throwing out the whole program and recoding
it from scratch. Too large a fraction of the program was wrapped around
the swapping of data to and from disk. Rewriting from scratch probably
took less of my time than porting would have, or at least comparable
time. The result was a fraction of the code size/complexity and
generally a much cleaner, easier-to-maintain, and better running
program.
Ron Shepard
<860e22f1-2995-49e8...@z8g2000prd.googlegroups.com>,
Jinsong Zhao <Jinson...@gmail.com> wrote:
It depends on the rest of the code, which you have not shown.
Sometimes there is a simple replacement, sometimes there isn't.
If the code being executed at this ponit is isolated, and the GOTO
is branching back to where it came from originally, then what is
really occurring in the code is equivalent to an internal subroutine
call. In that case, you could replace this with a CONTAINS
subprogram in a straightforward way.
But if the above is being used to build a finite state machine with
spaghetti code, then it would be difficult to replace even in modern
fortran. This is something that I do occasionally, and it has
always bothered me why fortran made this programming task so
difficult. Spaghetti code with assigned goto is about the only way
to do it, and now it looks like assigned goto is going to disappear
from the standard language, so the situation is going from bad to
worse.
$.02 -Ron Shepard
Terence
Yes! If I have this statement in a program being automatically
converted,
ASSIGN 123 TO JUMP
then I replace this with
JUMP=1
and store the label 123 as the reference for JUMP=1 in an list
indexed by JUMP.
Then the next ASIGN that refers to the same variable JUMP with a
different label
ASSIGN 456 TO JUMP
is also processed and the reference label is stored as the second
occurrence of use and this statement replaced by
JUMP=2
When the statement is found that uses variable JUMP and the labels
given:-
GO TO JUMP,(123,456)
Then this statement is replaced, using the indexed order of labels,
by
GO TO (123,456, , , ),JUMP
for as many refences as were indexed and so on.
This replaces the use of assigned GOTOs and the ASSIGN astatements
with a computed GOTO
One can also replace this form as follows
IF(JUMP.EQ.1) GO TO 123
IF (JUMP.EQ.2) GO TO 456
QED
Jinsong Zhao
Thank you very much. I got it.
if (computed) GOTO was deleted from the future Fortran standard, the
fate of those old programs ......
Regards,
Jinsong
viper-2
> Responding to "user1", Arjen and "dpb",
>
> It's not entirely what you refer to as "my views" that drive my
> comments, but the fact that the greater part of my faithful clients
> are in third world countries where the AT and 386 still reign supreme.
A good way to maintain the economic and power gap between the Third
World and the developed world, is to encourage just this dependence on
near obsolete (if not obsolete) technology. If that's the goal, then
encouraging your clients to stick with f77 and AT's is a good
strategy.
I've worked with supposedly progressive companies in Jamaica where
their senior engineers- influenced by First World actors - considered
integrating intelligent software into manufacturing automation to be
"futuristic", and engineering research and development simply not
needed.
I began learning Fortran 90 in February of this year, having not
touched the language (f77) since 1983. Personally, I was blown away 2
days ago when I discovered that Fortran 90 introduced recursive
procedures and optional parameters. I celebrated for a day! I haven't
yet had the time to play with pointers, objects and other features
introduced by f90/95 yet, but I really appreciate the milestones
Fortran has achieved compared with the power of other languages, e.g.,
Lisp.
I think that attitudes bordering on disparagement of f90/95 vis a vis
f77 - especially where this has an influence on retarding
technological development in the Third World - should be sucked up in
a black hole where there's no escape.
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: a...@codeartnow.com
Ron Shepard
<7b0eff47-f042-4820...@y34g2000prb.googlegroups.com>,
Jinsong Zhao <Jinson...@gmail.com> wrote:
> if (computed) GOTO was deleted from the future Fortran standard, the
> fate of those old programs ......
A computed goto can be replaced in a straightforward way with select
case.
goto ( 100, 200, 300, 400 ), igo
is the same as
select case (igo)
case (1); goto 100
case (2); goto 200
case (3); goto 300
case (4); goto 400
end select
It is a little wordy when used this way, but of course the select case
statement is more general than for just this purpose. The efficiency
should be about the same in either case (compared to a string of IF
statements), they are both table-indexed branches. For example, for a
large number of possible values for "igo", the compiler could implement
a binary search into the table in either case.
$.02 -Ron Shepard
glen herrmannsfeldt
> I began learning Fortran 90 in February of this year, having not
> touched the language (f77) since 1983. Personally, I was blown away 2
> days ago when I discovered that Fortran 90 introduced recursive
> procedures and optional parameters. I celebrated for a day! I haven't
> yet had the time to play with pointers, objects and other features
> introduced by f90/95 yet, but I really appreciate the milestones
> Fortran has achieved compared with the power of other languages, e.g.,
> Lisp.
Recursive procedures are nice, but not used all that
often. A large fraction of recursive algorithms are
better implemented without recursion. Fortran probably
did it right, having recursion as an optional attribute.
In C, all functions are recursive, needed or not.
-- glen
viper-2
> viper-2 <visio...@mail.infochan.com> wrote:
> > I began learning Fortran 90 in February of this year, having not
> > touched the language (f77) since 1983. Personally, I was blown away 2
> > days ago when I discovered that Fortran 90 introduced recursive
> > procedures and optional parameters. I celebrated for a day! I haven't
> > yet had the time to play with pointers, objects and other features
> > introduced by f90/95 yet, but I really appreciate the milestones
> > Fortran has achieved compared with the power of other languages, e.g.,
> > Lisp.
>
> Recursive procedures are nice, but not used all that
> often. A large fraction of recursive algorithms are
> better implemented without recursion.
Recursion is invaluable for operations on trees. It is true that we
often use recursion when sometimes iteration would do the work,
perhaps more efficiently - but recursion can be such fun!
I've been googling FFTs for use in my C-Graph project, and was
surprised to learn that there is a recursive f90 version authored by
Singleton that is comparatively efficient. I haven't yet studied the
code, though. I'll combine that with my linear algebra review -
whenever I get to it.:-)
Terence
Ah, no, not quite.
Because once you have the computed GOTO structure, then this is
extremely easily replaced with the CASE structure, and
GOTO (123,456), JUMP
becomes
SELECT CASE JUMP
CASE 1
go to 123
CASE 2
go to 456
END SELECT
But you can see why I prefer the computed GOTO as a one-liner.
robin
> Recursive procedures are nice, but not used all that
> often.
Depends on the applications, but there are certain
classes of algorithms where recursion is important.
These areas include list processing, compiling,
and graphics.
> A large fraction of recursive algorithms are
> better implemented without recursion.
In general, no, because to implement a recursive
routine without using a recursive facility,
one requires knowledge in advance of the size of arrays
needed to handle the recursion.
Many of the algorithms needing recursion are
expressed simply using recursive techniques --
and clumsily without.
robin
news:ebc120a6-e321-43b2...@x6g2000vbg.googlegroups.com...
> I began learning Fortran 90 in February of this year, having not
> touched the language (f77) since 1983. Personally, I was blown away 2
> days ago when I discovered that Fortran 90 introduced recursive
> procedures and optional parameters. I celebrated for a day! I haven't
> yet had the time to play with pointers, objects and other features
> introduced by f90/95 yet, but I really appreciate the milestones
> Fortran has achieved compared with the power of other languages, e.g.,
> Lisp.
Recursion has been available in PL/I since 1966,
and Algol since c. 1960.
Many other features added in F90 have been available
in PL/I since that time.
viper-2
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in messagenews:gr6sks$1ve$1...@naig.caltech.edu...
> > Recursive procedures are nice, but not used all that
> > often.
>
> Depends on the applications, but there are certain
> classes of algorithms where recursion is important.
> These areas include list processing, compiling,
> and graphics.
>
> > A large fraction of recursive algorithms are
> > better implemented without recursion.
>
> In general, no, because to implement a recursive
> routine without using a recursive facility,
> one requires knowledge in advance of the size of arrays
> needed to handle the recursion.
>
> Many of the algorithms needing recursion are
> expressed simply using recursive techniques --
> and clumsily without.
I'm sure Glen knows that. I think he might have been referring to
stylistic preference, rather than the use of iteration for problems
that inherently prescribe recursive solutions.
Schemers for example often show a preference for recursion over
iteration - when coding in other languages - even when the iterative
solution is more efficient and transparent.
viper-2
What took Fortran so long to catch up (with a recursive facility)?
Would this have been the focus on efficient numeric computation that
is its hallmark?
alexei....@gmail.com
> What took Fortran so long to catch up (with a recursive facility)?
> Would this have been the focus on efficient numeric computation that
> is its hallmark?
If left unspecified this is mostly a question of implementation,
I doubt there were many compilers that didnt provide any form
of recursion. You may not even notice that you are using it:
for instance specifying "-fopenmp" for gfortran implies "recursive"
attribute on *all* functions. Just because requirements for
recursion safety are similar to those for thread safety.
Alexei
Ron Shepard
<fa8e2836-6d38-437d...@r18g2000vbi.googlegroups.com>,
viper-2 <visi...@mail.infochan.com> wrote:
> What took Fortran so long to catch up (with a recursive facility)?
> Would this have been the focus on efficient numeric computation that
> is its hallmark?
I think it is probably the principle of avoiding dynamic memory
allocation. F77 can be implemented without using dynamic memory
allocation at all. I doubt that many of the newer compilers
implemented it that way, but it could be done, and probably was in
most implementations on older computers. This static-memory-only
model is why, for example, f77 did not allow a character(*) dummy
argument to appear both on the left and right of the equal sign in
certain expressions. Recursive subprograms require dynamic memory
allocation (e.g. stack allocation of local variables). Those
compilers that did support recursive subprograms in fortran as an
extension (and many did) used an underlying dynamic memory
allocation, either within the language itself, or based on
OS-specific support.
You are right that support of recursive subprograms does involve
some overhead that requires compromise in efficiency. That was
probably a factor too. But if the decision had been made early to
support other types of dynamic memory usage, then I think allowing
recursive subprograms would have followed soon thereafter. And if
you look at the languages that did support dynamic allocation, none
of them were ever as popular as fortran for scientific and
engineering number-crunching applications (pascal, basic, ada,
etc.). F90 and later does require dynamic memory allocation in
various places, such as array operations. So once dynamic memory
support is available within the language for these other purposes,
recursive subprograms could be added with little extra effort and
relatively little loss in computational efficiency.
Many recursive algorithms can be, and certainly have been,
implemented in fortran without recursive subprograms. Even with
recursive subprogram support in f90 and later, that is still the
best way to implement many such algorithms.
$.02 -Ron Shepard
nm...@cam.ac.uk
robin <rob...@bigpond.com> wrote:
>"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message news:gr6sks$1ve$1...@naig.caltech.edu...
>
>> better implemented without recursion.
>
>In general, no, because to implement a recursive
>routine without using a recursive facility,
>one requires knowledge in advance of the size of arrays
>needed to handle the recursion.
Oh, really? Not once you are allowed pointers inside allocatable
objects, one doesn't.
Actually, it can be done with just allocatable objects, but I agree
that is considerably more tedious. Often more efficient, though.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
viper-2 <visi...@mail.infochan.com> wrote:
>
>Would this have been the focus on efficient numeric computation that
>is its hallmark?
No. The main reason was a stick-in-the-mud mindset. There were
Fortran II compilers that supported recursion, efficiently, as well
as many others later - but that didn't (and doesn't) stop its
opponents claiming that it is inherently inefficient. Most other
languages have similar blind spots.
There ARE real problems in Fortran to with with SAVE and recursion,
but they aren't half as tricky as is often made out.
Recursion is very important in numeric computation when building
2-D optimisers, quadrature etc. out of 1-D ones.
Regards,
Nick Maclaren.
jfh
Even the Scots can find Maclarens confusing. This university used to
have a Professor Duncan M'Laren Young Sommerville, who had been a
student and then a lecturer at St Andrews before he came to NZ. He was
a Fellow of both the Edinburgh Mathematical Society and the Royal
Society of Edinburgh. One of them said McLaren in his obituary, the
other M'Laren, and the St Andrews history of mathematics web site says
Maclaren!
John Harper, Victoria University, Wellington, New Zealand.
glen herrmannsfeldt
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message news:gr6sks$1ve$1...@naig.caltech.edu...
>> A large fraction of recursive algorithms are
>> better implemented without recursion.
> In general, no, because to implement a recursive
> routine without using a recursive facility,
> one requires knowledge in advance of the size of arrays
> needed to handle the recursion.
Factorial is popular for introductory
programming classed, yet is obviously easy to do
with a simple loop. Quicksort is easily described
recursively, but with fairly high overhead. As
the recursion (or array size) needed is less
than log2 of the length of the array being
sorted it isn't hard to use an array big enough
for the largest problem.
> Many of the algorithms needing recursion are
> expressed simply using recursive techniques --
> and clumsily without.
In some cases. Recursive descent parsers for one,
though by the time you do good error recovery you
lose much of the advantage.
-- glen
glen herrmannsfeldt
> On Apr 5, 7:05?pm, viper-2 <visio...@mail.infochan.com> wrote:
>> What took Fortran so long to catch up (with a recursive facility)?
>> Would this have been the focus on efficient numeric computation that
>> is its hallmark?
> If left unspecified this is mostly a question of implementation,
> I doubt there were many compilers that didnt provide any form
> of recursion.
In the Fortran 66 days, and likely Fortran 77 days, static
allocation was common. It is faster on many machines for
one reason. The OS/360 Fortran compilers use a static
save area for saving the return address. If a routine does
manage to call itself the return address is overwritten.
The TOPS-10 Fortran compiler in the PDP-10 used static
allocation for variables, but a stack for the return address.
I did once try doing recursion with arrays for all local
variables and a variable to index the current iteration.
For compilers based on a C back end, stack allocation
is fairly likely, though.
-- glen
glen herrmannsfeldt
> Recursion is very important in numeric computation when building
> 2-D optimisers, quadrature etc. out of 1-D ones.
I remember some quadrature (integration) routines that included
multiple copies of the same routine in a library, with different
names. That allowed for a limited recursion depth. Though
many of the fancier adaptive routines don't work so well nested.
-- glen
Louis Krupp
> robin <rob...@bigpond.com> wrote:
>> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message news:gr6sks$1ve$1...@naig.caltech.edu...
> (snip)
>
>>> A large fraction of recursive algorithms are
>>> better implemented without recursion.
>
>> In general, no, because to implement a recursive
>> routine without using a recursive facility,
>> one requires knowledge in advance of the size of arrays
>> needed to handle the recursion.
>
> Factorial is popular for introductory
> programming classed, yet is obviously easy to do
> with a simple loop. Quicksort is easily described
> recursively, but with fairly high overhead. As
> the recursion (or array size) needed is less
> than log2 of the length of the array being
> sorted it isn't hard to use an array big enough
> for the largest problem.
I would expect less overhead (and more flexibility) using an array than
pushing activation records on the stack.
Then there's tail recursion. We all have a at least a vague idea of
what it is, and I will now proceed to tell you everything I know beyond
that.
OK. I'm done. Thank you for listening.
Louis
JussiJ
> My preferred development environment is actually the old DOSBrief editor
> w/ using its ability to compile in background and return to the point of
> any compilation errors. I've used that particular editor since my first
> PC so it has become so much a habit the missing or klunky emulation in
> VS doesn't make up for the missing features.
I would have though this was still possible.
For example the Zeus IDE does a pretty good job of emulating Brief
keyboard.
It can also run a background compiler/linker/make, capture the output
and let you navigate to a line in a files that produced the
compilation
error. It even does Fortran syntax highlighting.
But I would have though there would be several programmers editors
that
could provide this type of functionality.
Jussi Jumppanen
Author: Zeus for Windows IDE
dpb
> On Apr 3, 12:13 am, dpb <n...@non.net> wrote:
>
>> My preferred development environment is actually the old DOSBrief editor
>> w/ using its ability to compile in background and return to the point of
>> any compilation errors. I've used that particular editor since my first
>> PC so it has become so much a habit the missing or klunky emulation in
>> VS doesn't make up for the missing features.
>
> I would have though this was still possible.
The biggest problem is the ALT+ key gets (silently) trapped by the IDE
and changes context from the editor function to the IDE main menus.
This can lead to making some fairly major blunders if don't notice and
hit the wrong thing. It takes a real knack of timing to avoid it;
enough so that I've given it up for the most part for anything other
than the simplest of chores.
It also doesn't do split windows w/ more than one file which is often a
real aid.
That's a couple of the most notable; there are other annoyances as well.
It does have better syntax highlighting and context-sensitive help and
so on that go w/ the graphic editor instead of text-based, but overall
I'll take the operation over the show...
> For example the Zeus IDE does a pretty good job of emulating Brief
> keyboard.
...
Yes, JussiJ, I've eval'ed your editor; it is nice but I've not spent the
money. One lack is it can't process Brief macros (or at least didn't
when I looked) and I've customized the language macros at some length
for my own preferences. I've little doubt that w/ effort it could be
made to approximate mine; I've just not wanted to spend the effort or
money since I'm retired from active consulting so I don't actually code
"in anger" any longer.
--
JussiJ
> the IDE and changes context from the editor function to the IDE
> main menus.
In Zeus if any keyboard function is bound to any Alt+key keyboard
combination then as you, say the Alt key never gets to the menu
and gets (silently) trapped.
But to have the menus work like a normal Windows application just
means using a keyboard mapping that does not bind to the Alt key.
For example the Zeus Simple keyboard mapping is one such mapping
and with this keyboard active, the menus work just like any other
Windows application ;)
But as a long time user of the Brief editor myself, I can't live
without these Alt function bindings.
So I make use of a work around where by the menu can be activated
using a single Alt key press and release. Once the menu has been
activated the Alt+keys work as expected.
> It also doesn't do split windows w/ more than one file which is
> often a real aid.
That is correct. This is still a limitation of Zeus :(
> One lack is it can't process Brief macros (or at least didn't
> when I looked)
It can't do Brief macros but you can write Zeus macros in Lua,
Python, VbScript, JavaScript, even Tcl ;)
And zeus has many other features (i.e. project/workspace management,
syntax highlightingcode folding, code templates, etc etc) that are
not found in the original Brief ;)
dpb
...
>> One lack is it can't process Brief macros (or at least didn't
>> when I looked)
>
> It can't do Brief macros but you can write Zeus macros in Lua,
> Python, VbScript, JavaScript, even Tcl ;)
This OT here but the point I was making was as well as Zeus does what it
does, I've modified the Brief macros extensively and don't feel up to
rewriting them in another language.
That's not to say it _couldn't_ be done; just I'm not choosing to do
so... :)
--