Search results for query: *

yea i did try it in gfortran compiler and it did come out to real*8 so now i know i will not have to go thru and put extra labels such as dble(...) but only in certain places where definitely needed

or ok i see now why asked. I made an error in that post. I meant to ask, say have read that when have mixed types such as integer and real in for example r=a/i the result will be real*4 but now suppose have set REAL*8 a,r then will r=a/i be of precision real*8 or will it just be of default...

integer ofcourse by default

i have read that when have mixed types such as integer and real in for example r=a/i the result will be real*4 but now suppose have set integer*8 a,r then will r=a/i be of precision real*8 or will it just be of default precision real*4 ?

Using gfortran I had quite a long program with many recursive subroutines,an input and output file etc. etc. and compiling using gfortran -O3 -ffast-math ii.F03 vs compiling using just gfortran ii.F03 the ii.exe program ran usually around 4 to 5 times as fast for the same input file...

I was dividing floats by integers. Yea I know am going to get round off,floating point error no matter what. I was just asking if generally one way was better than the other. That is dividing floats as the program goes by one or smaller number of integers as i go or wait till at the end and then...

integer*8 lisf(17) nn=3 lisf=[1,1,2,(0,i=4,4*nn+5)] print*,lisf end But on the screen the entries after the 4th are invalid numbers,NOT all 0's. And on other occasions of similar types it does not even print out the entries >4 and if have more steps,assigning loops etc. get run time errors...

You are dividing integer by integer. I don't have that case at all. I am only multiplying integer times integer and at the end dividing floating point by the integers product which i presume should be more accurate or perhaps at worst same? than dividing the float by each integer at a time...

if all the variables at first are integer isn't integer multiplication supposed to be exact ? Even though i am getting very large numbers(as long as not overflow): anyway at the end i will have to divide a floating point number by the integer(s). There are several steps and at first i just...

So i would assume the compiler is going to do the same with either form and the .exe file will be exactly the same ?

if for example array is allocatable say of one dimension and already allocated then is it automatically set all elements to 0? I had always been doing array=0 which i have also seen in the literature of other people doing In fact i have been doing so for all arrays of any dimensions real or...

Interesting so these fort.1 , fort.10 are kind of 'reserved' or standard names. Anyway about 3 hours after my last post then it all the sudden went back to the usual correct way of writing to the same modinc395.t file for ALL files many months old with absolutely no change in the files nor...

mikrom (Programmer) 10 Aug 17 20:16 Don't use in read() the formst '(2(i3))' until you are sure that the input file is really so formatted - in your case it's not! " Yea I just left out a space or two above. but that is not the problem as even so it reads it correctly and i have made sure of...

all the sudden strange behavior using above compiler. For illustration My source file is named U1.f95 with the following code ------------------ open (1, file="modinc395.t",status="old",position="rewind",& action="read",iostat=ierror) read(1,'(2(i3))') nps,npmx ; print*,"nps,npmx",nps,npmx...

Thanks for the tip. The form write(*,*)"ls1(1,1)",ls1(1,1) DID work . Funny though because the write(1,*).... form did in fact write to the screen in most instances of other programs. The print "ls1(1,1)",ls1(1,1) form did not and in fact gave error Error: Missing leading left parenthesis...

Ok now i recall the logical comparison can only use a redefined scalar so the following gives no error. integer:: ls1(2,4),mlis(2,4) lenrec=1 nps=4 write(1,*)"ls1(1,1)",ls1(1,1) write(1,*)"ls1(1,:)",ls1(1,:) write(1,*)"ls1",ls1,"nps",nps i1=ls1(1,1) ; i2=ls1(2,1) i=1 do while(i1==i2.and.i<nps)...

integer:: ls1(2,4),mlis(2,4) lenrec=1 nps=4 write(1,*)"ls1(1,1)",ls1(1,1) write(1,*)"ls1(1,:)",ls1(1,:) i=1 do while(ls1(1,i)==lsl(2,i).and.i<nps+1) i=i+1 enddo end First of all it ignores the write statements if omit the do while... As it is it gives 'undefined reference error...

When you use in the main program instead of constants rather variables as arguments of the subroutine, then your approach will work" That is interesting also. Then again I ask the same question to the logic as to why that is necessary and if anyone has the same problem of not getting the...

I find the following also works: call rr(1,1) end recursive subroutine rr(j,k) if(j>3) then print*,k else m=k*j n=j+1 call rr(n,m) endif end That is for any integer symbols m,n as long as they are not k nor j. The question is why should it matter if i reuse either or...

Has anyone had this problem with the gfortran compiler call rr(1,1) end recursive subroutine rr(j,k) if(j>3) then print*,k else k=k*j call rr(j+1,k) endif end Clearly everything is well defined and should not be getting any run time errors such as 'segmentation... invalid...