blank in assignment Fortran IV
in [Fortran]
|
From: dpb on 4 Nov 2009 12:32 Alexandros Droseltis wrote: > Thank you all for your answer. The problem is that there is not a > function XRANF(-1) and the only thing that would make sense in the > given context would be that > > HX=HINF+HM*X RANF(-1) > > would mean > > X=RANF(-1) > HX=HINF+HM*X > > that is, RANF(-1) is assigned to X and then HX is computed. > > Could this be possible in Fortran IV? No. If I interpret your original post correctly, you have a piece of code you're attempting to read but not necessarily the entire working application. Assuming the blank is "real" and not simply an artifact of some reproduction process, the interpretation would have to be that of HX=HINF+HM*XRANF(-1) since blanks were never significant and the most logical conclusion is that there was a function XRANF() w/ the original application. The assumption that it would have been a uniform prng function is reasonable; to implement the code w/ a modern compiler either use the supplied intrinsic function in its place or another of your choice. --
From: James Van Buskirk on 4 Nov 2009 12:45 "Alexandros Droseltis" <usenet-1(a)alex-droseltis.com> wrote in message news:7ldplbF3dfsnbU1(a)mid.individual.net... > X=RANF(-1) > HX=HINF+HM*X If you just wanted to make this work, try: call random_number(x) hx = hinf+hm*x -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: Richard Maine on 4 Nov 2009 12:46 Alexandros Droseltis <usenet-1(a)alex-droseltis.com> wrote: > Thank you all for your answer. The problem is that there is not a > function XRANF(-1) and the only thing that would make sense in the > given context would be that > > HX=HINF+HM*X RANF(-1) > > would mean > > X=RANF(-1) > HX=HINF+HM*X > > that is, RANF(-1) is assigned to X and then HX is computed. > > Could this be possible in Fortran IV? No. It is not possible. Not even close. I already said what the blank means. That answer isn't going to change if you try reasking it in some other form. The blank means nothing and the code has the same effect as if the blank were not there. I am more than half suspicious that there might be a typo on this line, but I have insufficient data to make a good guess as to the typo. (No, I'm not prepared to go find a copy of the paper reference cited just to answer this). I went back and reread your original post carefully and noticed that you did not say you had actually run this line of code as is, but rather that you tried "using a random number, say TEMP, instead of RANF(-1)". Another universal principle is that it is better to show code than to describe it. In particular, show the code you actually ran rather than showing code that you did not run and trying to describe the differences between it and what you did run. If you did what I think you are trying to describe above, then I can guess pretty well why you are getting the described results. I think you are saying that you coded HX=HINF+HM*X TEMP and TEMP was some variable that was assigned random values. Reread my description of what blanks mean in versions of Fortran prior to f90. They mean nothing. (Diversions into contexts where they can mean something are not going to be helpful here; this isn't those contexts, or close to them.) Instead of trying to guess that this description might be incorrect, try to apply it to your code - the code that you actually ran rather than what is in the book. It shouldn't be that hard, but I'll help. Blanks mean nothing, so take it out as it is doing nothing other than misleading you. That gives your line as HX=HINF+HM*XTEMP I hope you can tell me what that line means. If there are any difficulties, I'll say that it means just what it looks like. No tricks. And it involves something named XTEMP. It has nothing to do with anything named TEMP, so it makes no difference what some TEMP thing might be. What, though, is XTEMP? This is probably a good place to mention the merits of using IMPLICIT NONE. That wasn't available in Fortran IV, but it will be available in any compiler you will find today (most certainly including g95, which you mentioned). Of course, it can be a bother to use with old code that is full of undeclared variables. If you don't use IMPLICIT NONE, then typos and things like the above just turn into implicitly declared variables. You didn't intentionally declare a variable named XTEMP, but you appeared to be trying to use one, so the compiler implicitly declared it for you. You probably never gave XTEMP a value (since you didn't even intend for it to exist). That means it is technically undefined and invalid to use, but odds are at least reasonable that it might act as though it had the value zero, which would match your reported results. Well, my simple attempt to show that doesn't use zero, but then I don't know what switches you used or anything else about the context. I used g95 with program clf HINF = 42. HM = 2. HX=HINF+HM*XTEMP write (*,*) hx end and it gave me 38.000263; evidently some random garbage in XTEMP. Note, however, that even if old code might makek it painful to use IMPLICIT NONE, there are other things compilers can do to help you. For example, if I use g95's -Wall switch to turn on most warnings, it tells me HX=HINF+HM*XTEMP 1 Warning (113): Variable 'xtemp' at (1) is used but not set -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 4 Nov 2009 14:23 Alexandros Droseltis <usenet-1(a)alex-droseltis.com> wrote: > Thank you all for your answer. The problem is that there is not a > function XRANF(-1) and the only thing that would make sense in the > given context would be that > HX=HINF+HM*X RANF(-1) > would mean > X=RANF(-1) > HX=HINF+HM*X > that is, RANF(-1) is assigned to X and then HX is computed. > Could this be possible in Fortran IV? I don't believe that would happen for any Fortran version in a million years. (Wait for Fortran 1002010) C has the assignment operator, instead of assignment statement, such that you could write: hx=inf+hm*(x=ranf(-1)); The parentheses are required, as = has a low precedence. That is extremely unlikely in Fortran IV, and there are no () in yours. There were Fortran IV compilers that allowed multiple statements on a line using unusual characters, such as the X'ff' character (that is, char(255) in Fortran 90 terms). The X'ff' character would be unprintable, and might print as blank on some printers, such as the 1403. In that case, the statements would be executed left to right, and there would have to be an = operator. There might have been some Fortran IV compilers that accepted = in place of .EQ., the relational equality operator. That also seems unlikely to help your problem. -- glen
From: glen herrmannsfeldt on 4 Nov 2009 14:30
nmm1(a)cam.ac.uk wrote: (snip, I wrote) >>Still my favorite are those for OS/360 which can be declared >>either REAL or INTEGER and return the appropriate value. > You could do that for DOUBLE PRECISION and COMPLEX as well :-) Well, not for a 31 or 32 bit generator. If you don't care about wasting bits you might as well go for COMPLEX*16 and REAL*16, or even COMPLEX*32. For those not following the discussion, the OS/360 calling convention returns INTEGER values in general register 0, REAL in floating point register 0, COMPLEX*8 in F0 and F2. Also, REAL*16 also in F0 and F2, and finally COMPLEX*32 in all four floating point registers. -- glen |