Clarify An Old Question: define a user data containing array with dimensions decided in running time
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing arraywith dimensions decided in running time
Next: reasons for failure
From: Richard Maine on 18 May 2010 22:46 Hifi-Comp <wenbinyu.heaven(a)gmail.com> wrote: > 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? Not trivially. I can think of only two "outs" that might have a chance of comming close. Both have caveats. I still think your best bet is with the declaration I showed. It depends, however, on how the values for vector tend to get defined. If you normally define vector with a whole array assignment, then the f2003 allocate-on-assignment should take care of it. If you just do x%vector = some_array_expression then it ought to do the right thing automatically. It will also work if you assign to x, as that acts like an assignment of the component. It won't work if you assign individual elements as in x%vector(1) = something x%vector(2) = something_else You can do assignments like that after vector is allocated (possibly by a whole_array assignment), but not as the first time you "touch" it. Maybe if most of the usage is ok, you could get by with only a few explicit allocations. The other possibility that occurs to me is to use a PDT (parameterized derived type). You could do something like type user_data(dim) integer, len :: dim real(dbl_ad) :: scale real(dbl_ad) :: vector(dim) end type Then declare your variables like type(user_data(n)) :: x, y(30),z(100,10) This has all kinds of consequences, though. I hesitate to really recommend it. Probably the biggest consequence is that very few compilers have implemented this feature yet. It appears to be about the last f2003 feature to be implemented in compilers. I am told that is because it is hard to implement (and user demand has not been high, giving a pretty poor demand/cost ratio). The latest IBM compiler (for machines that you probbaly don't have) claims to implement it. When I commented about that compiler being the first one, I think I recall that someone corrected me by pointing out that Cray has had it for a while, but you probably don't have any of those machines either. It has taken so much time for the commercial compilers to do this feature that I wouldn't hold my breath waiting for it to get into the free compilers. Maybe I'll be surprised; I suppose it could happen. A related consequence is that even if you do find a compiler that claims to implement PDTs, odds are pretty high that it is going to be buggy. Early implementations of complicated features like tend to be. Also, there are consequences in terms of the Fortran code, independent of compiler implementation issues. Declarations like the above make the variables in question automatic variables. That might be ok, but automatic is incompatible with some other things. For example, you can't have a local saved automatic variable; the automatic and save inherently conflict. (Automatic means to allocate/deallocate on each entry/exit, while save means to retain values, including size). All in all, while it might be the closest thing to what you are asking for, I can't recommend that path - not now anyway. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 20 May 2010 01:49
Jim Xia <jimxia(a)hotmail.com> wrote: > 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. But he specifically said that he wanted to input the value at run time. That was the whole point of the original question. He already knew and was using the *MUCH* simpler f95 way to do it at compile time. Because all the values in a particular execution were the same (as I think was mentioned in the previous thread), doing it at compile time doesn't involve PDTs at all. You just use a named constant to specify the dimension, as in his original f95 code. That's why I just showed a LEN parameter without bothering to discuss the alternative - the LEN parameter fit the stated problem, while a KIND parameter doesn't. Admitedly, there could be other problems that the KIND parameter could solve. If you wanted to allow different variables to have different values of the parameter, but those values were known at compile time, then a KIND parameter would be appropriate. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |