Compiler Error
in [Fortran]
|
From: Colin Watters on 12 Jun 2010 04:02 "rfengineer55" <rfengineer55(a)aol.com> wrote in message news:c1f2ccfa-768f-48f3-b91d-f8892537f660(a)k39g2000yqb.googlegroups.com... > On Jun 11, 12:05 pm, dpb <n...(a)non.net> wrote: > > rfengineer55 wrote: > > > > ... > > > > > ... That's how you choose to see the situation, and I'm not at all > > > interested in hearing about it. So airing your interpretation is > > > going > > > to do nothing but waste bandwidth. > > > > ... > > > > OK, then, <plonk>... > > > > If you think > > > > a) Showing the generation of your posted error message in two lines of > > executable code to demonstrate the "why" of the message explicitly, and > > > > b) The suggestion to just slow down and "think first, program second" > > are a waste of bandwidth, then > > > > c) I agree that in this case they undoubtedly are and regret wasting my > > time. > > > Just to be certain to not ruffle any feathers in the future, I've > > notified my newsreader to be sure to skip any future threads so as to > > minimize any chance to offend... > > > > -- > > I hesitated to respond to dpb's post but for the record. I embrace his > suggestions about modifying my fortran code. That's why I'm here. His > comments about my flailing, throwing code at my computer and needing > to think logically is what I'm not interested in hearing about because > it has nothing to do with the problem at hand. > What you fail to appreciate is that _problems_ need _people_ to solve them. DPB, Richard, and most of the regulars here (with one notable exception) try to help _people_ solve thier problems. Yes, one way to do that is to show the solution to the problem, and they do that a lot. But the other important way is to impart general advice about how such problems should be solved, and the way _people_ should behave in order to be most likley to solve them. I've watched all your threads over the past 3 or 4 days, and I never cease to be amazed at the wealth of useful advice that is available here. You don't sound like a young person to me, but from the tone of the above, and some of your other posts, I think you still have a little growing up to do. You have managed to offend dpb sufficiently that he has set his newsreader omit your postings from his display, so you won't hear from him again. If I were you I'd take a lot more care from now on. I know Richard has a number of regular clf posters on his newsreaders kill-list, you don't want to be one more. -- Qolin Email: my qname at domain dot com Domain: qomputing
From: Ron Shepard on 12 Jun 2010 08:30 In article <huv18e$gu9$1(a)news.eternal-september.org>, dpb <none(a)non.net> wrote: > > You use a 36 bit machine to convert from 60 bit words to 32 bit? > > Sure, makes _perfect_ sense, doesn't it... :) > > The powers that be decreed the only machine we had access to for the > editing work was the 10. Once that was to the point it would compile we > then did get time of the IBM to debug. This was not an unusual situation at all in the past. Often there was a smaller machine, like a pdp-11 or a vax, that supported multiple users with terminals (timesharing was a new thing), so this is where the user would do simple things like editing. The production machine was faster, but it only ran one job at a time in batch mode with no interactive access. The TOPS-10 and TOPS-20 machines had very nice interactive, multiple-user, interfaces (in some ways nicer even than some current command-line interfaces), so it would make sense for users to use a machine like this for editing code that would eventually run on other machines. $.02 -Ron Shepard
From: dpb on 12 Jun 2010 09:09 Ron Shepard wrote: > In article <huv18e$gu9$1(a)news.eternal-september.org>, > dpb <none(a)non.net> wrote: > >>> You use a 36 bit machine to convert from 60 bit words to 32 bit? >> Sure, makes _perfect_ sense, doesn't it... :) >> >> The powers that be decreed the only machine we had access to for the >> editing work was the 10. Once that was to the point it would compile we >> then did get time of the IBM to debug. > > This was not an unusual situation at all in the past. Often there > was a smaller machine, like a pdp-11 or a vax, that supported > multiple users with terminals (timesharing was a new thing), so this > is where the user would do simple things like editing. The > production machine was faster, but it only ran one job at a time in > batch mode with no interactive access. The TOPS-10 and TOPS-20 > machines had very nice interactive, multiple-user, interfaces (in > some ways nicer even than some current command-line interfaces), so > it would make sense for users to use a machine like this for editing > code that would eventually run on other machines. Oh, I didn't say (or mean to imply) it was unusual ... :) ; it indeed was the norm. And, for many things it was quite a satisfactory arrangement. Porting from 60-bit to 32 via 36 with the machine-dependent stuff in this code was "not so much". The clue things weren't going to go swimmingly was the DOE PM whose response to all things regarding the differences between machines was "It's just FORTRAN, isn't it?" That could only compile/run same source on the DEC before moving to the IBM for the limited time was a prime reason the end result ended up being so slow because we never had opportunity to develop machine routines to do the bit masking on those index variables or work out any other magic so every loop access in the iterative solver ended up w/ a mask and shift. CDC didn't decode those bits in loop addressing so it was transparent on the original machine by comparison. --
From: Louis Krupp on 12 Jun 2010 23:34 On 6/12/2010 8:54 PM, Steve Lionel wrote: > On 6/11/2010 9:35 PM, Richard Maine wrote: >> All this extensive complaint in response to a single post by dpb where >> he showed exactly how to duplicate the message in question, which is >> certainly useful, and he accurately described the ISAM feature being >> used and the general process of how to sucessfully deal with the kind of >> code in question. > > Not that it's particularly relevant, but this code is not using ISAM. It > is using direct access files with a non-standard syntax. VMS also had > "indexed organization" files, which were ISAM, and which VMS Fortran > supported, but that's not being used here. > FWIW, in another file, the OP is (or was, before certain lines were commented out) using ISAM: c open (unit=amdb,status='old',access='keyed', open (unit=amdb,status='old', 2 file=amdbname,form='formatted',iostat=iostat,err=200) c c c read (amdb,810,key=header_key,iostat=iostat,err=2000) amrec read (amdb,810,iostat=iostat,err=2000) amrec .... write (amkey,809) ichankey,latkey,lonkey 809 format (i4.4,i3.3,i4.4) c read (amdb,810,keyid=3,keyge=amkey,err=150,iostat=iostat) amrec read (amdb,810,err=150,iostat=iostat) amrec 810 format (a2400) Louis
From: e p chandler on 13 Jun 2010 15:25
"Louis Krupp" wrote > FWIW, in another file, the OP is (or was, before certain lines were > commented out) using ISAM: > c open (unit=amdb,status='old',access='keyed', > open (unit=amdb,status='old', > 2 file=amdbname,form='formatted',iostat=iostat,err=200) > c read (amdb,810,key=header_key,iostat=iostat,err=2000) amrec > read (amdb,810,iostat=iostat,err=2000) amrec > write (amkey,809) ichankey,latkey,lonkey > 809 format (i4.4,i3.3,i4.4) > c read (amdb,810,keyid=3,keyge=amkey,err=150,iostat=iostat) amrec > read (amdb,810,err=150,iostat=iostat) amrec > 810 format (a2400) Understanding how the ISAM was used might be important for historical purposes, but in this particular application it is not needed, for two reasons. I won't show the relevant code. 1. The flat file extracted from the data base, which the OP is using is already sorted on the frequency part of the primary key. So one pass through the data file, excluding unwanted frequencies, works quite well and is certainly fast enough. 2. The ISAM key scheme is part of a complicated optimization which was designed to exclude records by latitude and longitude *without* doing an actual distance calculation. It basily calculated points due N, E, W and S of the center of the target circle, then used max and min lat. and long. to form a bounding rectangle. Stations outside this rectangle are rejected without calculating the distance. BUT this actually does not work! The earth is not flat! In fact the OP complained to me that the original program (with ISAM commented out) excluded too many stations when the radius was small, say 100 miles or so. Replacing the complicated key logic with a simple for all records in the input file if frequency is too low, next record if frequency is too high, end of run if distance is less than radius then print reports else next record works quite well. Selecting within 100 miles of Detroit returned reasonable results. -- Elliot |