Clarify An Old Question: define a user data containing array with dimensions decided in running time
in [Fortran]
|
Prev: reshape efficiency
Next: parameter incosistency
From: Gordon Sande on 19 May 2010 08:50 On 2010-05-18 22:51:21 -0300, Hifi-Comp <wenbinyu.heaven(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.
From: glen herrmannsfeldt on 19 May 2010 11:57 Gordon Sande <Gordon.Sande(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. Also, it would seem that you should be able to mix methods 1 and 3, subdivide an allocatable array through subroutine arguments. I don't know why one would want to do that, but it would seem that it should be legal. I can probably think of a few reasons: If one had many small arrays, and wanted to be able to quickly do unformatted I/O, to save and restore state. Other than I/O, to process many small arrays in some cases as one large array. More efficient use of cache, with contiguous storage. (snip) -- glen
From: Richard Maine on 19 May 2010 12:12 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Gordon Sande <Gordon.Sande(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
From: glen herrmannsfeldt on 19 May 2010 16:58 Richard Maine <nospam(a)see.signature> wrote: (snip, I wrote) >> 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. TYPE(User_Data):: x, y(30),z(100,10) y and z are arrays of TYPE(User_Data). Maybe that is just an example, and the real program doesn't have arrays. It seems, though, that the OP considers doing all the ALLOCATEs to be too much work. > 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. But I was wondering if all the old tricks from Fortran 66 and Fortran 77 days, such as passing part of an array to an assumed size dummy, still worked with arrays of structures. It doesn't seem that is easier than the ALLOCATE, but the post that I was following up seemed to imply that it wasn't allowed. -- glen
From: Richard Maine on 19 May 2010 17:59
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip, I wrote) > > >> 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. > > TYPE(User_Data):: x, y(30),z(100,10) > > y and z are arrays of TYPE(User_Data). As I said in the para you quote above "Well, there are some of those, but that's another matter." You found the "some of those" that I was referring to, but you missed the "but that's another matter" part. The OP's question was about the component VECTOR. It cannot be assumed size. > But I was wondering if all the old tricks from Fortran 66 and > Fortran 77 days, such as passing part of an array to an assumed > size dummy, still worked with arrays of structures. Yes, they do work. It just doesn't have any relevance to the OP's question. Note, in case you are unclear on the nature of his question, that he stated that my post answered it, which I take as pretty good evidence that I understood the question. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |