Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Colin Watters on 15 Jul 2010 15:25 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:i1l2f1$dqb$1(a)news.eternal-september.org... > > My "intern" is going to start working on the /save problem in a month > or two. We are going to try the brute force approach of initializing > all local variables to zero using execution statements, not data > statements. > Then here's an idea, fwiw. Surround each block of initializations with an IF DEBUG block. Eg: IF(DEBUG(304)) then xx1 = 0d0 xx2 = 0d0 : (etc) endif Declare the DEBUG array in common in an include file, dimension it to the number of routines in the program, and INCLUDE it in all the routines as you work on them. Of course, use a separate element of the array for every routine. You'll need to keep a list of numbers to names. Arrange a way so you can set or clear selected (or all) elements of DEBUG at program start-up. Now you can investigate which routines actually need the initialzations, without having to recompile. This is useful because it lets you find the actual cause of the problem(s), and allows you to fix them properly. If you do this you should leave the data statements extant. You could also initialize to some global initial value instead of zero, again determined at run-time. (thus you can undo the effect of the data statements.) Other possibilities will occur to you. Like...instead of 10 separate statements, try call init(xx1,xx2,xx3,xx4,xx5,xx6,xx7,xx8,xx9,xx10) Fun and games! -- Qolin Email: my qname at domain dot com Domain: qomputing
From: Lynn McGuire on 15 Jul 2010 15:41 >> My "intern" is going to start working on the /save problem in a month >> or two. We are going to try the brute force approach of initializing >> all local variables to zero using execution statements, not data >> statements. >> > > Then here's an idea, fwiw. > > Surround each block of initializations with an IF DEBUG block. Eg: > > IF(DEBUG(304)) then > xx1 = 0d0 > xx2 = 0d0 > : (etc) > endif > > Declare the DEBUG array in common in an include file, dimension it to the > number of routines in the program, and INCLUDE it in all the routines as > you work on them. Of course, use a separate element of the array for every > routine. You'll need to keep a list of numbers to names. > > Arrange a way so you can set or clear selected (or all) elements of DEBUG > at program start-up. Now you can investigate which routines actually need > the initialzations, without having to recompile. This is useful because it > lets you find the actual cause of the problem(s), and allows you to fix > them properly. > > If you do this you should leave the data statements extant. > > You could also initialize to some global initial value instead of zero, > again determined at run-time. (thus you can undo the effect of the data > statements.) > > Other possibilities will occur to you. Like...instead of 10 separate > statements, try > > call init(xx1,xx2,xx3,xx4,xx5,xx6,xx7,xx8,xx9,xx10) > > Fun and games! > Nice idea. Did I mention the 3,000 subroutines and functions ? 650,000 lines of code ? Thanks, Lynn
From: Colin Watters on 15 Jul 2010 16:56 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:i1noad$tqk$1(a)news.eternal-september.org... >>> My "intern" is going to start working on the /save problem in a month >>> or two. We are going to try the brute force approach of initializing >>> all local variables to zero using execution statements, not data >>> statements. >>> >> >> Then here's an idea, fwiw. >> >> Surround each block of initializations with an IF DEBUG block. Eg: >> >> IF(DEBUG(304)) then >> xx1 = 0d0 >> xx2 = 0d0 >> : (etc) >> endif >> >> Declare the DEBUG array in common in an include file, dimension it to >> the >> number of routines in the program, and INCLUDE it in all the routines as >> you work on them. Of course, use a separate element of the array for >> every >> routine. You'll need to keep a list of numbers to names. >> >> Arrange a way so you can set or clear selected (or all) elements of >> DEBUG >> at program start-up. Now you can investigate which routines actually >> need >> the initialzations, without having to recompile. This is useful because >> it >> lets you find the actual cause of the problem(s), and allows you to fix >> them properly. >> >> If you do this you should leave the data statements extant. >> >> You could also initialize to some global initial value instead of zero, >> again determined at run-time. (thus you can undo the effect of the data >> statements.) >> >> Other possibilities will occur to you. Like...instead of 10 separate >> statements, try >> >> call init(xx1,xx2,xx3,xx4,xx5,xx6,xx7,xx8,xx9,xx10) >> >> Fun and games! >> > > Nice idea. Did I mention the 3,000 subroutines and functions ? > 650,000 lines of code ? > > Thanks, > Lynn A 3000 element logical array is peanuts. (OK, you knew that...) If you are prepared to use brute force (your term!) you may as well add a tiny bit of finesse... it costs very little extra if done from the start and may just pay you back nicely. -- Qolin Email: my qname at domain dot com Domain: qomputing
From: Ron Shepard on 17 Jul 2010 00:47 In article <i1mca4$426$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > > > Fortran does not go in for mandatory enforcement of programming style by > > the language spec. It is much more about providing the programmer with > > options. Many of those style options can be verified/enforced if that is > > one's inclination. > > Maybe, but it does seem that some rules, or rule changes, were > meant to discourage some uses. One example is the removal of the > use of REAL varaibles in DO loops, added in Fortran 77, then removed > in Fortran 90. Yes there can be problems in doing it, but, as > you say the language shouldn't enforce the style. I could probably > think of some others, but that one comes to mind first. I would say this issue is a little more than "style". This was a mistake in the f77 standard, simple as that. Not a fatal flaw, but a mistake nonetheless. It should have been corrected shortly thereafter with a minor fortran revision (1980 or 1981), but that was delayed about a decade until f90, so that was the earliest that it could have been corrected. I think of "style" issues as several functionally equivalent ways of doing something, but some are deemed "better" than others because of style preferences. Integer and real do loop variables are not equivalent in this sense, the differences are more fundamental. $.02 -Ron Shepard
From: sturlamolden on 17 Jul 2010 08:50
On 15 Jul, 09:14, n...(a)cam.ac.uk wrote: > That's nothing - C99 has introduced complex time :-) I see that can be very useful. |