Author 
Message 
tachyo #1 / 12

matlab to fortran
Hi all, I've been convinced to convert my matlab code to fortran90 code for the sake of saving vast amounts of time (matlab code took days to run). This is my first ever time programming in fortran, and it seems I'm having a little issue with one piece of my old matlab code and am hoping that someone here might be able to help me out converting it to fortran...This is the matlab code: p=0; for i=1:n for j=1:n p=p+1; for k=1:m do stuff to generate matrix sub_boxes end dlmwrite(['cudata' int2str(p) '.csv'],sub_boxes,','); end end Basically what it does is write the data contained in the matrix sub_boxes to a file called cudata1.csv, cudata2.csv,...,cudata(n*n).csv. I have all the for loops and the stuff inside the for loops converted to fortran, except for the file output part. I'm having trouble trying to work out how to append the value of p to the filename for each iteration of the loop. I'd really appreciate it if someone could help this extreme newbie with converting this little snippet of code to fortran :) Thanks in advance!!!

Sun, 16 Jul 2006 12:20:18 GMT 


James Van Buskir #2 / 12

matlab to fortran
Quote: > Basically what it does is write the data contained in the matrix sub_boxes > to a file called cudata1.csv, cudata2.csv,...,cudata(n*n).csv. I have all > the for loops and the stuff inside the for loops converted to fortran, > except for the file output part. I'm having trouble trying to work out how > to append the value of p to the filename for each iteration of the loop.
character(80) filename ... p = p+1 write(filename, '(a,i0,a)') 'cudata', p, '.csv' open(10,file=filename) ! write current block close(10)  write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D85, & 6.0134700243160014d154/),(/'x'/)); end

Sun, 16 Jul 2006 13:49:45 GMT 


Tom Micevsk #3 / 12

matlab to fortran
... Quote: > p=0; > for i=1:n > for j=1:n > p=p+1; > for k=1:m > do stuff to generate matrix sub_boxes > end > dlmwrite(['cudata' int2str(p) '.csv'],sub_boxes,','); > end > end > Basically what it does is write the data contained in the matrix sub_boxes > to a file called cudata1.csv, cudata2.csv,...,cudata(n*n).csv. I have all > the for loops and the stuff inside the for loops converted to fortran,
... just letting you know that fortran uses column major order (i think that's the correct term), not row major order like some other languages (matlab?). so, for maximum efficiency, the left most array index should vary most rapidly. in other words, for an array a(p,q,r), you should set up loops like this: do k=1,r do j=1,q do i=1,p a(i,j,k) calcs in here enddo enddo enddo

Sun, 16 Jul 2006 13:35:13 GMT 


Jan C. Vorbrügge #4 / 12

matlab to fortran
Quote: > write(filename, '(a,i0,a)') 'cudata', p, '.csv'
Although I like the i0 format, in this case I'd prefer to use a fixed length with zero fill  that's in.n for some suitable value of n, right? That makes it easier to get all files displayed (and automatically processed in a command file, if needed) in proper order. Jan

Sun, 16 Jul 2006 21:34:35 GMT 


Matthew C Rober #5 / 12

matlab to fortran
On Wed, 28 Jan 2004 14:20:18 +1000, "tachyon" Quote:
>p=0; >for i=1:n > for j=1:n > p=p+1; > for k=1:m > do stuff to generate matrix sub_boxes > end > dlmwrite(['cudata' int2str(p) '.csv'],sub_boxes,','); > end >end
character(len=4) :: filen character(len=24) :: filename p=0 do i=1,n do j=1,n p=p+1 do k=1,m <...> end do read(filen,*) p filename = "cudata"//filen//".csv" open(71,file=filename) <perform write operations> close(71) end do end do You may have to fiddle with this a bit to deal with leading blanks, etc. If you have problems, post back here. A few tips for coming to Fortran from Matlab (which is how I came to Fortran, incidentally...) always, always, always use IMPLICIT NONE in your code. Learn how to use assumed shape arrays and stick everything in a module if at all possible. Good Luck!

Sun, 16 Jul 2006 23:31:22 GMT 


James Van Buskir #6 / 12

matlab to fortran
Quote: > > write(filename, '(a,i0,a)') 'cudata', p, '.csv' > Although I like the i0 format, in this case I'd prefer to use a fixed > length with zero fill  that's in.n for some suitable value of n, right? > That makes it easier to get all files displayed (and automatically processed > in a command file, if needed) in proper order.
I thought the task was to emulate num2str().  write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D85, & 6.0134700243160014d154/),(/'x'/)); end

Mon, 17 Jul 2006 00:00:15 GMT 


Richard Main #7 / 12

matlab to fortran
Quote: >> write(filename, '(a,i0,a)') 'cudata', p, '.csv' > Although I like the i0 format, in this case I'd prefer to use a fixed > length with zero fill  that's in.n for some suitable value of n, right? > That makes it easier to get all files displayed (and automatically processed > in a command file, if needed) in proper order.
Also one minor point. Probably classifies as a nit. But just in case... The OP said f90. The i0 format wasn't added until f95. Now the OP may have been speaking loosely; I've been known to just say f90 loosely on occasion, the differences between f90 and f95 being pretty minor. This is one of the minor differences. Most of today's f90 compilers do f95, but there are one or two exceptions. Those exceptions might not be important to the OP, and for all I know the few nonf95 compilers might happen to implement i0 anyway. But just in case the OP does happen to be using a compiler that doesn't do f95, mentioning this caveat might help keep him from puzzling over why it didn't work.  Richard Maine  Good judgment comes from experience; email: my first.last at org.domain  experience comes from bad judgment. org: nasa, domain: gov   Mark Twain

Sun, 16 Jul 2006 23:52:07 GMT 


Greg Chie #8 / 12

matlab to fortran
"Tom Micevski" wrote Quote: > just letting you know that fortran uses column major order > (i think that's the correct term), not row major order like > some other languages (matlab?).
Just to clarify... MATLAB also stores multidimensional matrices in columnmajor order; perhaps due to its Fortran legacy ;)  Best Regards, Greg Chien email: remove n.o.S.p.a.m. http://protodesigninc.com

Mon, 17 Jul 2006 00:50:55 GMT 


tachyo #9 / 12

matlab to fortran
Thanks for the help! All working now :)
Quote: > character(80) filename > ... > p = p+1 > write(filename, '(a,i0,a)') 'cudata', p, '.csv' > open(10,file=filename) > ! write current block > close(10) >  > write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D85, & > 6.0134700243160014d154/),(/'x'/)); end

Mon, 17 Jul 2006 08:10:48 GMT 


David Klei #10 / 12

matlab to fortran
Quote:
> "Tom Micevski" wrote > > just letting you know that fortran uses column major order > > (i think that's the correct term), not row major order like > > some other languages (matlab?). > Just to clarify... > MATLAB also stores multidimensional matrices in columnmajor order; > perhaps due to its Fortran legacy ;)
Or their common legacy with standard mathematical notation. If you are going to form Ax for a matrix A and vector x, you are much better off if A is stored in columnmajor order. I have a writeup of a fundamental reason why C and Fortran differ in their column ordering. I already posted it once to this newsgroup so I won't post it again. I can email it to you, or it can be accessed at: http://groups.google.com/groups?q=%22array+storage+in+fortran+and+c%2...  Use of tools distinguishes Man from Beast. And UNIX users from WINDOZE lusers.

Mon, 17 Jul 2006 15:08:04 GMT 


glen herrmannsfeld #11 / 12

matlab to fortran
(snip) Quote: > Or their common legacy with standard mathematical notation. > If you are going to form Ax for a matrix A and vector x, you are much > better off if A is stored in columnmajor order. > I have a writeup of a fundamental reason why C and Fortran > differ in their column ordering. I already posted it once to this > newsgroup so I won't post it again. I can email it to you, or it can > be accessed at: > http://groups.google.com/groups?q=%22array+storage+in+fortran+and+c%2...
In response to the google groups post, C does store arrays in consecutive storage without any additional pointers. In addition, C allows one to generate arrays of pointers to arrays, and reference them with the same notation. This is reasonably unrelated to multidimensional arrays. If one says, for example: double a[10][10]; One hundred array elements are allocate, and no pointer variables. If one says: double **b; one pointer and no numeric data elements are allocated. If one prints a Fortran 10 by 10 array with a statement such as WRITE(6,1) A 1 FORMAT(1X,10F10.3) one will immediately see which are rows and which are columns, and it won't print out the way a mathematician would normally print an array. If one is doing matrix multiplication, one multiplies the column of one by a row of another. In that case, there is no advantage of one storage method over the other. This is likely true for most mathematical matrix operations. For the above matrix/vector case, each row of the matrix is multiplied (dot product) by the column vector to generate one element of the column vector result. It seems to me easier (more cache efficient) in row major order. I used to know stories that column major order, like many old properties of DO loops, were related to index registers on the 704 or 709.  glen

Mon, 17 Jul 2006 16:36:06 GMT 


David Klei #12 / 12

matlab to fortran
Quote:
> (snip) > > Or their common legacy with standard mathematical notation. > > If you are going to form Ax for a matrix A and vector x, you are much > > better off if A is stored in columnmajor order. > > I have a writeup of a fundamental reason why C and Fortran > > differ in their column ordering. I already posted it once to this > > newsgroup so I won't post it again. I can email it to you, or it can > > be accessed at: > > http://groups.google.com/groups?q=%22array+storage+in+fortran+and+c%2... > In response to the google groups post, C does store arrays in > consecutive storage without any additional pointers. > In addition, C allows one to generate arrays of pointers to arrays, and > reference them with the same notation. This is reasonably unrelated > to multidimensional arrays. > If one says, for example: > double a[10][10]; > One hundred array elements are allocate, and no pointer variables. > If one says: > double **b; one pointer and no numeric data elements are allocated.
Agreed. Though this is not central to the article, I got this wrong. I will correct my local version, but unfortunately google will keep my goof for posterity... Quote: > If one prints a Fortran 10 by 10 array with a statement such as > WRITE(6,1) A > 1 FORMAT(1X,10F10.3) > one will immediately see which are rows and which are columns, > and it won't print out the way a mathematician would normally > print an array. > If one is doing matrix multiplication, one multiplies the column > of one by a row of another. In that case, there is no advantage > of one storage method over the other. This is likely true for > most mathematical matrix operations.
Agreed again. Stupid mistake. The argument in the article is I believe still correct, though I doubt anyone will trust it given the sloppiness I have showed :(  Use of tools distinguishes Man from Beast. And UNIX users from WINDOZE lusers.

Mon, 17 Jul 2006 18:49:29 GMT 


