equivalencing character*8 and double precision
in [Fortran]
|
From: Gordon Sande on 21 Jun 2010 19:19 On 2010-06-21 17:07:56 -0300, Lynn McGuire <lmc(a)winsim.com> said: >> *IF* you are doing D-I-Y dynamic allocation as was quite common in Fortran 77 >> then using automatic arrays may well do what you want. But you never quite get >> around to saying what the usage is so almost any advice will be suitable for >> some or other guessed at usage. But those guesses are unlikely to match your >> unstated usage so you get what you paid for, namely nothing of value. > > Yes, sorry, left off the common block: > > structure / type64 / > union > map > character c > end map > map > double precision d > end map > map > integer i > integer i_low > end map > map > logical l > integer l_low > end map > map > character*8 s > end map > end union > end structure > COMMON/VDYN/IERR,L8W7K1,VDY(2) > EQUIVALENCE (VDY (1), IVDY (1)) > EQUIVALENCE (VDY (1), LVDY (1)) > double precision VDY > record / type64 / IVDY (1) > record / type64 / LVDY (1) > > We have interfaces to actually allocate dynamic memory using > the c malloc, realloc and free library functions and pass back > a pointer relative to the vdyn common block. So that you see > code like: > call dfbk ('mynewbank', location, ncp) > do i = 1, ncp > vdy (location + i) = val (i) > end do Oh! That hack! The combination of the base address in a common block and the returned subscript is just an allocated variable with a subscript of "1". You will need to invent a bunch of new names. Hardly the end of the world. >> If the D-I-Y dynamic allocation allocates and then passes the results the >> equivalence to automatic arrays is trivial. If you are closer to running a heap >> then things are more complicated but it may be the case that >> ALLOCATEABLE rather >> than automatic will do the job. But that depends on things that you have not >> bothered to say. > > I would guess that we are closer to running a heap. We are > still on a f77 compiler at this time so we dont have access > to ALLOCATABLE. F77 is a subset of F90 so you can feed your F77 into an F90 compiler and never be aware of the difference, subject to the ability of the F90 to tolerate the extensions to F77 that you are using. Then you could use a few ALLOCATES here and there. VAX structures are a common extensions so that should not be an issue. > Thanks, > Lynn
From: Terence on 21 Jun 2010 21:09 On Jun 22, 3:25 am, Lynn McGuire <l...(a)winsim.com> wrote: > Is this considered bad code ? Or is this an extremely > common fortran compiler extension ? > > double precision vdy (1000000) > character*8 svdy (1000000) > equivalence (vdy, svdy) > > Thanks, > Lynn I often saw situations where you have to read data and you do not know which of several possible formats it might have. Examples include original format census files, oil well records, financial and production records or other historic files where formats have changed, over time but the set of original files (or more likely more recent copies of same) still exist for legal reasons as well as the corresponding original audited program source and executables.. So one alternative is to read all the files, identify the format and re-write a temporary new set in a common format. To do so might require being able some records from such a hisric file copy and explore the contents of records and known or suspected formats. So I see where such a requirement for general EQUIVALENCE facilities would be useful to the programmer if declared obsolete by some committee. My choice for the legacy problem would still be to use F77 to write test programs to explore the data and produce a common known format for any later processing. However there are other cases and situations and think there is some defence for not having to work around what was once a simple technique. Programing should always remain simple. Have you seen where Fortran is now rated as a useful language? And where it was? The origin of the repeated user conflict is cuased by the intersection of programing concepts and the outside real world, in that a program language should not be forced to know anything about the external devices nor the way data is externally stored, but should only rely on the right data coding being present in the identified internal arrays.
From: dpb on 22 Jun 2010 08:39 Lynn McGuire wrote: >> Which comes back to the issue of why do the different memory types >> have to overlay each other -- other than that's the way the memory >> heap was laid out? > > So that my code like this will work: > > call dfbk ('mynewbank', location, 20) > vdy (location + 1) = 1.0 > ivdy (location + 2).i = 6 > ivdy (location + 3).s = 'a name' > vdy (location + 4) = spec (4) > vdy (location + 5) = spec (9) > ivdy (location + 6).l = .false. > ivdy (location + 7).l = .true. > ... > > Thanks, > Lynn Oh, shades of the old online coal analyzer... :( It was coded w/ two arrays; CAL (supposedly "calibration data") and APP (the "application" definition), both clearly misnamed. The whole bloody thing was a series of references to numeric indices in the arrays indirectly referenced by the contents of the CALL array of a given number. Then to make it all secure, there was a user=editable access to the assignment of both the array values -- numeric for the CAL factors and a even to change the reference to variables by index changes in the APP array. All in the name of "flexibility" -- I made use of the "feature" once in 10 years to make a field change that actually was useful in solving a particular issue w/ a calibration of an unusual coal type; other than that it was simply a maintenance nightmare both in the code keeping track of who was on first and in field reliability as it was so easy to screw something up royally... This, I think, would need something like what I eventually did with that code and what somebody (Gordon, maybe?) already mentioned -- create a bunch of named variables for the references. I'd like to poke around a little but after the last couple of weeks of mostly sitting around and waiting, we're now in wheat harvest "in anger" and won't have much time for a while to do more than just look in quickly while checking weather/markets/etc., ... I see in passing somebody else later on mentioned that there are a few compilers that implement the DEC STRUCTURE; they obviously have forgotten or don't know about the side issues w/ initialization so we've (yet again) come full circle it would seem in the discussion... :) --
From: Lynn McGuire on 23 Jun 2010 12:43 > I note from Fortran 2003, 15.2.3: > "There is no Fortran type that is interoperable with a C union type." Yes, I am becoming painfully aware of that ! > As far as the Fortran standard, there is no requirement that double > precision and character*8 have the same size. It might be slightly > better to use REAL*8 instead, though that makes it non-standard > in a different way. I need the character*8 type badly. Did I mention that we have a fortran 66 interpreter built into our app for our users to add custom calculations ? At least one of our users has over 10,000 lines of our inline fortran built into their models. Yes, the interpreter is written in f77 code. But, I could possibly change the character*8 to character*4 if I had to. Possibly. > The C union allows one to do something like this, without the > requirement that they be the same size. > > So, assuming your compiler allows it, it is system dependent > that the two have the same size. The program will fail badly > if the sizes are different. Yes. It works for now. Who knows what the future will bring <shudder> ? I am eyeing all these mobile apps with much apprehension. Thanks, Lynn
From: Lynn McGuire on 23 Jun 2010 12:46
> Yes. I recall running into compilers that refused that kind of > equivalence. Luckily watcom fortran and intel fortran are not part of those. > I suppose it isn't surprsing that removing Hollerith usage was also what > I was doing when I ran into that problem. Removing the Hollerith has been difficult at best. > But in my case, that was about 30 years ago. :-) I don't recall the > details or what I ended up doing instead. But I sure do recall > concluding that I needed to pay attention to that particular bit in the > standard if I expected my code to be portable across compilers that I > had specific need for my code to work with. Thanks, Lynn |