f



Fortran to C to Fortran Arrays

I'm doing a little research. I want to create a multi-dimensional
array in fortran containing real values and pass it to a C/C++
program. In the C/C++ program the array will be loaded with values
gathered using a libjpeg library or something (haven't figured that
out yet). Then I want to return this array back to the Fortran
program, loaded with data so that it can be handled there. I have not
started to write code yet on this I am just researching some. Can this
be done?
0
deadpickle (60)
2/20/2009 1:56:49 AM
comp.lang.fortran 11941 articles. 1 followers. Post Follow

21 Replies
1439 Views

Similar Articles

[PageSpeed] 56

deadpickle wrote:
> I'm doing a little research. I want to create a multi-dimensional
> array in fortran containing real values and pass it to a C/C++
> program. In the C/C++ program the array will be loaded with values
> gathered using a libjpeg library or something (haven't figured that
> out yet). Then I want to return this array back to the Fortran
> program, loaded with data so that it can be handled there. I have not
> started to write code yet on this I am just researching some. Can this
> be done?
It is done, but more details are needed.  What compiler, how is the data 
passed (function call?)?

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford
0
garylscott (1355)
2/20/2009 2:22:54 AM
On Thu, 19 Feb 2009 17:56:49 -0800 (PST), deadpickle wrote:

> I'm doing a little research. I want to create a multi-dimensional
> array in fortran containing real values and pass it to a C/C++
> program. In the C/C++ program the array will be loaded with values
> gathered using a libjpeg library or something (haven't figured that
> out yet). Then I want to return this array back to the Fortran
> program, loaded with data so that it can be handled there. I have not
> started to write code yet on this I am just researching some. Can this
> be done?

In which syntax will you have main?
-- 
larry gates

There is, however, a strange, musty smell in the air that reminds me of
something...hmm...yes...I've got it...there's a VMS nearby, or I'm a Blit.
             -- Larry Wall in Configure from the perl distribution
0
larry553 (319)
2/20/2009 3:18:52 AM
deadpickle wrote:

> I'm doing a little research. I want to create a multi-dimensional
> array in fortran containing real values and pass it to a C/C++
> program. In the C/C++ program the array will be loaded with values
> gathered using a libjpeg library or something (haven't figured that
> out yet). Then I want to return this array back to the Fortran
> program, loaded with data so that it can be handled there. I have not
> started to write code yet on this I am just researching some. Can this
> be done?

If the dimensions are constants, then it is pretty easy.

Otherwise, about the easiest is to pass it to C as a one dimensional
array (in C it will be a pointer) and to compute the offset yourself.

The favorite way to pass multidimensional dynamically allocated
arrays in C is as arrays of pointers, but Fortran doesn't have
a feature like that.

There is no standard way to work with Fortran assumed shape arrays,
and the descriptors used with them.

-- glen

0
gah (12851)
2/20/2009 3:19:16 AM
On Thu, 19 Feb 2009 20:19:16 -0700, Glen Herrmannsfeldt wrote:

> There is no standard way to work with Fortran assumed shape arrays,
> and the descriptors used with them.

What are assumed-shape arrays?
-- 
larry gates

I knew I'd hate COBOL the moment I saw they'd used "perform" instead of
"do".
             -- Larry Wall on a not-so-popular programming language
0
larry553 (319)
2/20/2009 3:23:33 AM
Larry Gates wrote:

> On Thu, 19 Feb 2009 20:19:16 -0700, Glen Herrmannsfeldt wrote:

>>There is no standard way to work with Fortran assumed shape arrays,
>>and the descriptors used with them.

> What are assumed-shape arrays?

Passed by descriptor, such that the dimension information is
sent to the called routine without extra help (extra arguments).

-- glen

0
gah (12851)
2/20/2009 3:50:26 AM
On 20 Feb, 01:56, deadpickle <deadpic...@gmail.com> wrote:
> I'm doing a little research. I want to create a multi-dimensional
> array in fortran containing real values and pass it to a C/C++
> program. In the C/C++ program the array will be loaded with values
> gathered using a libjpeg library or something (haven't figured that
> out yet). Then I want to return this array back to the Fortran
> program, loaded with data so that it can be handled there. I have not
> started to write code yet on this I am just researching some. Can this
> be done?

Look into "Interoperability with C" in Fortran 2003. It's designed to
do exactly what you want. Have a look at

ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf

or a good, modern Fortran book.

Though full Fortran 2003 compilers are pretty thin on the ground, many
have this feature implemented. See

www.fortranplus.co.uk/resources/fortran_2003_compiler_support.pdf

where is says that both gfortran and g95, amongst other compilers,
have this implemented.

Hope this helps,

Ian
0
2/20/2009 8:25:15 AM
On Feb 20, 2:25=A0am, Ian Bush
<ianbush.throwaway.acco...@googlemail.com> wrote:
> On 20 Feb, 01:56, deadpickle <deadpic...@gmail.com> wrote:
>
> > I'm doing a little research. I want to create a multi-dimensional
> > array in fortran containing real values and pass it to a C/C++
> > program. In the C/C++ program the array will be loaded with values
> > gathered using a libjpeg library or something (haven't figured that
> > out yet). Then I want to return this array back to the Fortran
> > program, loaded with data so that it can be handled there. I have not
> > started to write code yet on this I am just researching some. Can this
> > be done?
>
> Look into "Interoperability with C" in Fortran 2003. It's designed to
> do exactly what you want. Have a look at
>
> ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf
>
> or a good, modern Fortran book.
>
> Though full Fortran 2003 compilers are pretty thin on the ground, many
> have this feature implemented. See
>
> www.fortranplus.co.uk/resources/fortran_2003_compiler_support.pdf
>
> where is says that both gfortran and g95, amongst other compilers,
> have this implemented.
>
> Hope this helps,
>
> Ian

I'm using ifort (intel fortran compiler). Can anyone offer a simple
example of passing a 3 dimension, allocatable fortran array to C then
back again. I know, I am probably asking quit-a-bit. By pointer do you
mean that you pass a one dimensional array to C from fortran?
0
deadpickle (60)
2/25/2009 3:06:23 AM
deadpickle wrote:
(snip)

> I'm using ifort (intel fortran compiler). Can anyone offer a simple
> example of passing a 3 dimension, allocatable fortran array to C then
> back again. I know, I am probably asking quit-a-bit. By pointer do you
> mean that you pass a one dimensional array to C from fortran?

These are with g95 and gcc...

       real x(4,4,4)
       do i=0,63
          x(1+mod(i,4),1+mod(i/4,4),1+i/16)=i
       enddo
       write(*,'(4f8.1)') x
       call cfunction(x)
       write(*,*)
       write(*,'(4f8.1)') x
       stop
       end

void cfunction_(float x[][4][4]) {
    int i;
    for(i=0;i<63;i++) x[i/16][(i/4)%4][i%4] += i;
    }

The first fills the array with 0 to 63 in array element
order (leftmost subscript varying faster).  The second
adds to each element 0 to 63, again in array element
order (rightmost varying fastest).

In C89, all except the leftmost subscript must be constants.
I believe that C99 removes this restriction.

-- glen

0
gah (12851)
2/25/2009 5:14:31 AM
On Tue, 24 Feb 2009 22:14:31 -0700, Glen Herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> deadpickle wrote:

> These are with g95 and gcc...
> 
>        real x(4,4,4)

> void cfunction_(float x[][4][4]) {

> In C89, all except the leftmost subscript must be constants.

s/subscript/dimension/ 

You can omit the leftmost dim as shown, or you can include it but it
is effectively ignored (since it isn't used in accesses, and C
implementations generally don't check bounds).

> I believe that C99 removes this restriction.

Right, C99 allows runtime expressions.

0
3/9/2009 4:55:08 AM
David Thompson <dave.thompson2@verizon.net> wrote:
> On Tue, 24 Feb 2009 22:14:31 -0700, Glen Herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
(snip) 

>> void cfunction_(float x[][4][4]) {
 
>> In C89, all except the leftmost subscript must be constants.
 
> s/subscript/dimension/ 
 
> You can omit the leftmost dim as shown, or you can include it but it
> is effectively ignored (since it isn't used in accesses, and C
> implementations generally don't check bounds).
 
>> I believe that C99 removes this restriction.
 
> Right, C99 allows runtime expressions.

That would make it a lot easier to do Fortran 66 style arrays,
which became assumed size in later versions.

Though Fortran 66 only allows variables, not expressions.

A large fraction of the numerical code from those days, though,
dimensions the dummy array (1), and computes the offset internally.

-- glen
 
0
gah (12851)
3/9/2009 10:30:35 AM
In article <gp2r4b$m7c$1@naig.caltech.edu>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>David Thompson <dave.thompson2@verizon.net> wrote:
>
>>> void cfunction_(float x[][4][4]) {
> 
>>> In C89, all except the leftmost subscript must be constants.
> 
>> s/subscript/dimension/ 
> 
>> You can omit the leftmost dim as shown, or you can include it but it
>> is effectively ignored (since it isn't used in accesses, and C
>> implementations generally don't check bounds).

Grrk.  Not quite.  The standard is spectacularly ambiguous in this
area (please ask for a writeup that describes that horror if you
are seriously into masochism), and there are circumstances when it
does matter.

>>> I believe that C99 removes this restriction.
> 
>> Right, C99 allows runtime expressions.
>
>That would make it a lot easier to do Fortran 66 style arrays,
>which became assumed size in later versions.
>
>Though Fortran 66 only allows variables, not expressions.

To a first approximation, C99 upgraded C's array support to the
level of Fortran 77.

>A large fraction of the numerical code from those days, though,
>dimensions the dummy array (1), and computes the offset internally.

Yes, the convention of using '1' was a common Fortran 66 compiler
hack, and was replaced by the much cleaner Fortran 77 '*'.


Regards,
Nick Maclaren.
0
nmm12 (1380)
3/9/2009 10:45:03 AM
nmm1@cam.ac.uk wrote:
(snip, I wrote)
 
>>A large fraction of the numerical code from those days, though,
>>dimensions the dummy array (1), and computes the offset internally.
 
> Yes, the convention of using '1' was a common Fortran 66 compiler
> hack, and was replaced by the much cleaner Fortran 77 '*'.

Yes, but more specifically it was also done for 2D arrays
for matrix operations.  One reason was that it allowed one routine
to process a general matrix, a triangular matrix such that the 
other triangle was not stored, or a symmetric matrix, again not
storing the other triangle.  

One that I remember was trying to get a subroutine working
with WATFIV.  WATFIV did bounds checking, so I couldn't get
away with (1).  What I really needed was N*N, but that wasn't
allowed.  I had to add another argument and pass N*N to the routine.

-- glen

0
gah (12851)
3/9/2009 11:23:17 AM
In article <gp2u74$m7c$6@naig.caltech.edu>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
> 
>>>A large fraction of the numerical code from those days, though,
>>>dimensions the dummy array (1), and computes the offset internally.
> 
>> Yes, the convention of using '1' was a common Fortran 66 compiler
>> hack, and was replaced by the much cleaner Fortran 77 '*'.
>
>Yes, but more specifically it was also done for 2D arrays
>for matrix operations.  One reason was that it allowed one routine
>to process a general matrix, a triangular matrix such that the 
>other triangle was not stored, or a symmetric matrix, again not
>storing the other triangle.  

Yes.  In Fortran 66, it was unclear that was legal.  There were enough
compilers that supported it and people that used it to get it into
Fortran 77, despite the ghastly "gotchas" it introduces.

>One that I remember was trying to get a subroutine working
>with WATFIV.  WATFIV did bounds checking, so I couldn't get
>away with (1).  What I really needed was N*N, but that wasn't
>allowed.  I had to add another argument and pass N*N to the routine.

Yes.  WATFIV restricted Fortran 66 slightly to make it possible to
do proper bounds checking - but how I wish that a modern compiler
would do it as reliably!  It can be done, and any compiler developer
wanting to know how (while not breaking compatibility) should contact
me by Email.


Regards,
Nick Maclaren.
0
nmm12 (1380)
3/9/2009 11:31:28 AM
On 2009-03-09 08:31:28 -0300, nmm1@cam.ac.uk said:

> In article <gp2u74$m7c$6@naig.caltech.edu>,
> glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>> 
>>>> A large fraction of the numerical code from those days, though,
>>>> dimensions the dummy array (1), and computes the offset internally.
>> 
>>> Yes, the convention of using '1' was a common Fortran 66 compiler
>>> hack, and was replaced by the much cleaner Fortran 77 '*'.
>> 
>> Yes, but more specifically it was also done for 2D arrays
>> for matrix operations.  One reason was that it allowed one routine
>> to process a general matrix, a triangular matrix such that the
>> other triangle was not stored, or a symmetric matrix, again not
>> storing the other triangle.
> 
> Yes.  In Fortran 66, it was unclear that was legal.  There were enough
> compilers that supported it and people that used it to get it into
> Fortran 77, despite the ghastly "gotchas" it introduces.
> 
>> One that I remember was trying to get a subroutine working
>> with WATFIV.  WATFIV did bounds checking, so I couldn't get
>> away with (1).  What I really needed was N*N, but that wasn't
>> allowed.  I had to add another argument and pass N*N to the routine.
> 
> Yes.  WATFIV restricted Fortran 66 slightly to make it possible to
> do proper bounds checking - but how I wish that a modern compiler
> would do it as reliably!  It can be done, and any compiler developer
> wanting to know how (while not breaking compatibility) should contact
> me by Email.

You seem to imply that Salford (now Silverfrost), NAG and Lahey/Fujitsu
(with stated exceptions) do not do it reliably. They all seem to take the
trouble to pass (hidden) descriptors and check against them. It has to
be enabled and results in object level incompatability with previously
compiled code. Most others treat assumed size as an unsolvable problem
but do not have the incompatabilty problems. Is there some level of
problem I missed in their documentation or did you overstate the issue?

I use this trio for their undefined variable checking and have not had to
push the corner cases on the subscript checking. The old pointer-number
based systems like KDF9 and Burroughs did the subscript checking in hardware
with no degradation in performance unlike all others.

> Regards,
> Nick Maclaren.


0
g.sande (1185)
3/9/2009 1:31:58 PM
In article <2009030910315516807-gsande@worldnetattnet>,
Gordon Sande  <g.sande@worldnet.att.net> wrote:
>> 
>> Yes.  WATFIV restricted Fortran 66 slightly to make it possible to
>> do proper bounds checking - but how I wish that a modern compiler
>> would do it as reliably!  It can be done, and any compiler developer
>> wanting to know how (while not breaking compatibility) should contact
>> me by Email.
>
>You seem to imply that Salford (now Silverfrost), NAG and Lahey/Fujitsu
>(with stated exceptions) do not do it reliably. They all seem to take the
>trouble to pass (hidden) descriptors and check against them. It has to
>be enabled and results in object level incompatability with previously
>compiled code. Most others treat assumed size as an unsolvable problem
>but do not have the incompatabilty problems. Is there some level of
>problem I missed in their documentation or did you overstate the issue?

Hell, no!  I stated it.  But, upon rechecking, I am out of date - at
least for NAG in at least one case.

So I take that remark back - with apologies for maligning the compiler
developers who have got that right.


Regards,
Nick Maclaren.
0
nmm12 (1380)
3/9/2009 2:12:48 PM
On 2009-03-09 11:12:48 -0300, nmm1@cam.ac.uk said:

> In article <2009030910315516807-gsande@worldnetattnet>,
> Gordon Sande  <g.sande@worldnet.att.net> wrote:
>>> 
>>> Yes.  WATFIV restricted Fortran 66 slightly to make it possible to
>>> do proper bounds checking - but how I wish that a modern compiler
>>> would do it as reliably!  It can be done, and any compiler developer
>>> wanting to know how (while not breaking compatibility) should contact
>>> me by Email.
>> 
>> You seem to imply that Salford (now Silverfrost), NAG and Lahey/Fujitsu
>> (with stated exceptions) do not do it reliably. They all seem to take the
>> trouble to pass (hidden) descriptors and check against them. It has to
>> be enabled and results in object level incompatability with previously
>> compiled code. Most others treat assumed size as an unsolvable problem
>> but do not have the incompatabilty problems. Is there some level of
>> problem I missed in their documentation or did you overstate the issue?
> 
> Hell, no!  I stated it.  But, upon rechecking, I am out of date - at
> least for NAG in at least one case.
> 
> So I take that remark back - with apologies for maligning the compiler
> developers who have got that right.

They should be given more credit than they usually get. It seems that the
speed benchmarks dominate too many evaluations. With notable exceptions the
cost of development is greater than the cost of running production. And the
cost of having wrong results in production outweighs either!

> Regards,
> Nick Maclaren.


0
g.sande (1185)
3/9/2009 2:46:44 PM
In article <2009030911464316807-gsande@worldnetattnet>,
Gordon Sande  <g.sande@worldnet.att.net> wrote:
>
> [ Fortran compiler developers who support reliable array bounds
> checking ]
>
>They should be given more credit than they usually get. It seems that the
>speed benchmarks dominate too many evaluations. With notable exceptions the
>cost of development is greater than the cost of running production. And the
>cost of having wrong results in production outweighs either!

I am in complete agreement!


Regards,
Nick Maclaren.
0
nmm12 (1380)
3/9/2009 3:19:09 PM
On Mar 9, 3:46 pm, Gordon Sande <g.sa...@worldnet.att.net> wrote:
> On 2009-03-09 11:12:48 -0300, n...@cam.ac.uk said:
>
>
>
> > In article <2009030910315516807-gsande@worldnetattnet>,
> > Gordon Sande  <g.sa...@worldnet.att.net> wrote:
>
> >>> Yes.  WATFIV restricted Fortran 66 slightly to make it possible to
> >>> do proper bounds checking - but how I wish that a modern compiler
> >>> would do it as reliably!  It can be done, and any compiler developer
> >>> wanting to know how (while not breaking compatibility) should contact
> >>> me by Email.
>
> >> You seem to imply that Salford (now Silverfrost), NAG and Lahey/Fujitsu
> >> (with stated exceptions) do not do it reliably. They all seem to take the
> >> trouble to pass (hidden) descriptors and check against them. It has to
> >> be enabled and results in object level incompatability with previously
> >> compiled code. Most others treat assumed size as an unsolvable problem
> >> but do not have the incompatabilty problems. Is there some level of
> >> problem I missed in their documentation or did you overstate the issue?
>
> > Hell, no!  I stated it.  But, upon rechecking, I am out of date - at
> > least for NAG in at least one case.
>
> > So I take that remark back - with apologies for maligning the compiler
> > developers who have got that right.
>
> They should be given more credit than they usually get. It seems that the
> speed benchmarks dominate too many evaluations. With notable exceptions the
> cost of development is greater than the cost of running production. And the
> cost of having wrong results in production outweighs either!
>

seconded,

Ian


0
3/9/2009 3:27:26 PM
In article <gp2rvf$q5k$1@soup.linux.pwf.cam.ac.uk>, nmm1@cam.ac.uk 
wrote:

> To a first approximation, C99 upgraded C's array support to the
> level of Fortran 77.

One of the important features that appeared first in f77 is the 
ability to specify both upper and lower bounds in arrays.


   real a(-10:10,-2:100)

This allows one to map more closely the actual formulas to the 
programming language (i.e. FORmula TRANslation).  In C and other 
lesser languages, the lower bound is always fixed (at 0 or 1 
usually), and the programmer is responsible for keeping track of the 
offsets.

I guess it is a matter of taste and/or programming style whether 
this is more often used, or is more important, than the ability to 
have expressions in array dimension declarations.  I think I 
personally use the lower bound feature more than the expression 
feature, and when I use other languages, it is one of the features 
that I miss the most.  It is interesting to me that this important, 
and trivial to implement, feature has not appeared in other popular 
programming languages after being in fortran for more than 30 years, 
which is about three times infinity when it comes to computers.  To 
me, it shows that scientific and engineering programming is not 
important to the design and evolution of these other languages.

$.02 -Ron Shepard
0
ron-shepard (1197)
3/9/2009 4:32:13 PM
Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> One of the important features that appeared first in f77 is the 
> ability to specify both upper and lower bounds in arrays.

(Well, other languages had it earlier, I believe ALGOL and its
descendants PL/I and PASCAL.  But for Fortran, yes, 77.)
 
>   real a(-10:10,-2:100)
 
> This allows one to map more closely the actual formulas to the 
> programming language (i.e. FORmula TRANslation).  In C and other 
> lesser languages, the lower bound is always fixed (at 0 or 1 
> usually), and the programmer is responsible for keeping track of the 
> offsets.
 
> I guess it is a matter of taste and/or programming style whether 
> this is more often used, or is more important, than the ability to 
> have expressions in array dimension declarations. 

Well, C89 only allows constants, compared to F66 allowing variables
(for dummy argument dimensions).  Getting the constants right can
be significant work, (though it isn't hard with a preprocessor),
but it is significantly more work without variable dimensions.

The usual solution in C89 was (and still is) to use arrays of
pointers to arrays, all dynamically allocated.  
That works fine in C, but not so well in Fortran.

-- glen
0
gah (12851)
3/9/2009 5:58:09 PM
On Tue, 24 Feb 2009 19:06:23 -0800 (PST), deadpickle
<deadpickle@gmail.com> wrote:

>
>I'm using ifort (intel fortran compiler). Can anyone offer a simple
>example of passing a 3 dimension, allocatable fortran array to C then
>back again. I know, I am probably asking quit-a-bit. By pointer do you
>mean that you pass a one dimensional array to C from fortran?

Here is an example using Intel Fortran 10.0 and the Microsoft VC 8.0
compiler & linker. Some things to note:

1) Fortran typically converts all global names (function names, common
blocks, etc) to upper case for exporting, so the linker knows them by
the uppercase name even though the source code may have them in lower
case. You can often override this with compiler options, but uppercase
is typically the default.

2) Fortran often places underscore(s) at the beginning and/or at the
end of the global name exported to the linker. So if you are mixing
compilers that do not do the same thing, then you may have to manually
change the name on one side or the other to get them to match. In the
example below I did not have to do this because both Intel Fortran and
MSVC put a single underscore at the beginning, so the linker can match
them up without me having to fix up the names manually.

3) Type data lengths are of course platform dependent, so none of this
is guaranteed to be portable. But a real*8 on the Fortran side is
equivalant to a double on the C side (both 8 bytes, IEEE, etc.), and a
default integer on the Fortran side is equvalent to a long on the C
side (both 4 bytes, 2's complement, etc.).

4) Fortran memory for arrays is column based (first index varies
first), whereas C memory for arrays is row based (last index varies
first). So you need to make allowances for this. If you are treating
the multidimensional array on the C side as a single dimensional
array, then you will have to do your own indexing manually. In my
example I just used a macro to treat the indexing as a 0-based Fortran
array (first index varies first). But if you want to use the bracket
notation on the C side and actually treat it as a multi-dimensional
array, then the easiest thing to do is to treat it as a
multi-dimensional transpose of the Fortran array. e.g., if it is a
(3,4,5) on the Fortran side, then treat it as a [5][4][3] on the C
side.

5) Fortran is pass-by-reference (purists, don't shoot me here) for
most practical purposes, so expect the addresses of the arguments to
be passed. C is pass by value, so expect to get pointers to the data
types on the C side.

James Tursa

----------------------------------------------------------------------------

      program multif2c
      real*8, allocatable :: x(:,:,:)
      integer istat, i, j, k
      allocate(x(3,4,5),stat=istat)
      if( istat /= 0 ) then
          write(*,*) 'Allocation failed'
          stop
      endif
      call cfunction(x,3,4,5)
      write(*,*) 'The x array from c is:'
      do k=1,5
          write(*,*) 'x(:,:,',k,') ='
          do i=1,3
              write(*,*) x(i,:,k)
          enddo
      enddo
      deallocate(x)
      end program

----------------------------------------------------------------------------

#define X(i,j,k) x[(i)+((j)+(k)*(*n))*(*m)]  // Use 0-based Fortran
indexing

void CFUNCTION(double *x, long *m, long *n, long *p) {
    long i, j, k;
    double y = 0.0;
    
    for( k=0; k<*p; k++ ) {
        for( j=0; j<*n; j++ ) {
            for( i=0; i<*m; i++ ) {
                X(i,j,k) = ++y;
            }
        }
    }
}

0
3/10/2009 7:03:15 AM
Reply: