Clarify An Old Question: define a user data containing array with dimensions decided in running time
in [Fortran]
|
Prev: F2003 Standard question to constructors (type name = generic name)
Next: Clarify An Old Question: define a user data containing arraywith dimensions decided in running time
From: Hifi-Comp on 19 May 2010 09:31 I am basically redefing the intrinsic real numbers with the user typer to overload a fortran code may not easy be written by me. I have no control of how many real variables (scalars and arrays) and how they will be used in the code. I really appreciate all the answers. It might be hopeless to solve my problem but I learn more about dynamic arrays. Thanks a lot! On May 19, 8:50 am, Gordon Sande <Gordon.Sa...(a)gmail.com> wrote: > On 2010-05-18 22:51:21 -0300, Hifi-Comp <wenbinyu.hea...(a)gmail.com> said: > > > > > > > My original question was not clear and get sidetracked. Hence I am > > trying to clarify the question: > > > Currently I have the following: > > > INTEGER,PARAMETER:: n=3 > > > TYPE,PUBLIC:: User_Data > > REAL(DBL_AD)::scale > > REAL(DBL_AD)::vector(n) > > END TYPE User_Data > > > TYPE(User_Data):: x, y(30),z(100,10) > > > In the real situation, I want the user of compiled code to input n > > (remain the same throughout the calculation) and with almost no > > changes to the original code. > > > Richard suggested to change the type definition as follows > > TYPE,PUBLIC:: User_Data > > REAL(DBL_AD)::scale > > REAL(DBL_AD),ALLOCATABLE::vector(:) > > END TYPE User_Data > > > However, I don't want to insert allocate statement for each variables > > of User_Data as there are many such types in the overall program. It > > seems to me I should be able to do something like > > > ALLOCATE(USER_DATA%VECTOR(N)) > > > to fix the dimension of vector, and all the variables of User_Data > > will then know the dimension already. Is it posslbe to achieve this? > > Using F95 and doing "dynamic" allocaion of a number (A) of arrays gives > you broadly three options: > > 1. use the older F77 methods were you allocate an array of size > n*A and then subdivide it yourself. Takes at least A statements to > do this and requires the arrays be arguements after subdivision. > > 2. make the arrays automatic which requires that they be arguements > > 3. use A allocate statements. > > Since you have chosen to use a user defined type you have ruled out 1 and 2. > Even if you had not ruled ot 1 and 2 they take about as much effort as just > allocating the arrays. > > The statement "there are many such types in the overall program" has a confused > ring about it. Possible meaings include: > > 1. There are many SEPARATE arrays in SEPARATE pieces of code. > > 2. There are many SEPARATE arrays used in many pieces of code. > > 3. There are arrays that get reused in many pieces of code. > > If the arrays are in a module then they will need to be allocated exactly > once in the main and used throughout the code. There is no need to allocate > the (already allocated) arrays in the various places that use those modules. > It is possible to hear your statement as objecting to having to allocae the > same arrays in each piece of code that uses them. Sure hope that is not > what you have been lead into thinking. > > If there are R reuses of A arrays then in static allocations there will be > R*A places where a global search will find the size assumming that the arrays > are reused using common. If the reuse is with modules the there will only be > A instances of the size and R use statemets for the module. Modules win! > Use of allocate for user types will mean that modules must be used.- Hide quoted text - > > - Show quoted text -
From: Hifi-Comp on 19 May 2010 16:33 Yes, Richard, PDTs seem like a perfect solution. Since it is not readily available and robust enough in most compiler. I might have to wait. Thanks a lot for sharing your knowledge. On May 19, 12:12 pm, nos...(a)see.signature (Richard Maine) wrote: > glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > Gordon Sande <Gordon.Sa...(a)gmail.com> wrote: > > (snip) > > > > Using F95 and doing "dynamic" allocaion of a number (A) of arrays gives > > > you broadly three options: > > > > 1. use the older F77 methods were you allocate an array of size > > > n*A and then subdivide it yourself. Takes at least A statements to > > > do this and requires the arrays be arguements after subdivision. > > > > 2. make the arrays automatic which requires that they be arguements > > > > 3. use A allocate statements. > > > > Since you have chosen to use a user defined type you have ruled out 1 and 2. > > > Even if you had not ruled ot 1 and 2 they take about as much effort as just > > > allocating the arrays. > > > Do you mean that there are no assumed size arrays of structures? > > Not that I would recommend method 1, but I didn't realize that > > it was disallowed. > > Relook at the OP's question. These are not arrays *OF* structures. Well, > there are some of those, but that's another matter. These are arrays > that are *COMPONENTS* of structures, which is a completely different > thing. No, you can't have an assumed-size component. It wouldn't even > really make sense, as you define components in the type declaration, > which applies to objects that aren't even dummy arguments. > > Note my separate reply explaining that automatic is actually an option > with f2003 (though not with f95, so your statement is correct). I'm not > sure it is a good option, but it can be done with PDTs. > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain- Hide quoted text - > > - Show quoted text -
From: Jim Xia on 19 May 2010 23:03
On May 19, 4:33 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote: > Yes, Richard, PDTs seem like a perfect solution. Since it is not > readily available and robust enough in most compiler. I might have to > wait. Thanks a lot for sharing your knowledge. PDT is one way to solve your problem. However there are issues in choosing KIND vs LEN type parameters. In Richard's example, he shows LEN type parameter which may or may not solve your problem. If you'd like to have a fixed size component vector known at compile time, you may want to choose KIND type paremeters. That'll give you less worry when you're passing this object around as actual arguments. XL Fortran has PDT support in V13.1 Cheers, Jim |