View previous topic :: View next topic |
Author |
Message |
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Dec 05, 2015 9:06 pm Post subject: User-Defined TYPES - What Practical Usefulness ... If Any ? |
|
|
I've seen this new-fangled (to me at least) concept in several posts over time but a recent one grabbed my attention because the example given was very clear on its useage and made me look into it a little more.
It seems to me that it's simply just a way of grouping a number of variables, with different types) into one 'super-variable type' (for want of a better expression).
Having read a little about it I get the impression it was introduced to make Fortran a little more 'similar' to C/C++ structures ? Thus satisfying probably deluded, superiority-complexed C programmers egos no end, but with no obvious benefits to a layman like myself in these matters.
My trawling for explanations have led to little or no real explanation(s) of their benefits, surely there must be some practical advantages to using them ? or are they really just cosmetic, maybe on the route to converting Fortran users into C-users bing the long-term aim ?
It's another 'modern' concept which I'm reluctant (no maybe lets update that to a loath) as an F77 stalwart to jump into not knowing the benefits (and no doubt drawbacks) to doing so.
Are there maybe some clever speed benefits associated ?
... or Is it just beneficial in terms of organisation (grouping variables together which are related) ?
What are the drawbacks of using them (if any) ? ...
How easy is it to use them cross-modules/functions/subroutines (yes all of them !) and are there any pitfalls to avoid ?
Are there any memory penalties associated with using them, or maybe there are benefits ?
Maybe there might be some implications for ALLOCATION of array variables which may be contained within the structures ?
I'm having difficulty finding any article which adresses and answers these type of questions.
Also can anyone maybe suggest a good read where F90 'advanced capabilities' (sic) in general are discussed in a 'this is why it's better' way rather than the usual rigid syntactical explanation of their useage with little or no real explanation ? In other words a dummies guide to why I should be using the various newities of F90.
[Addendum: The more I see and read about F90, whilst I'm sure it was intended in the most positive way when first conceived, I get the feeling that it was in fact originally conceived as a subversive attempt to bring Fortran users (good-ol' scientists & engineers) around to C programmers (IT-ers) way of thinking and eventually to try to sound the death knoll on Fortran, which we all know is ridiculous idea, unless of course your an IT man who'd like it to be so in their all-conquering quest for superiority and world dominance .. but I'm getting carried away ! LOL ] |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Dec 06, 2015 12:16 am Post subject: |
|
|
John,
I am a bit with you on this.
I find derived types are very useful for assembling data. It groups the data and makes it’s name more meaningful.
However, Fortran has become far more complex. Why do we need polymorphic types and all the new code structures in F03 and F08?
All I see of this is more and more complex data structures and code.
The computer scientist’s justification for this complexity was “object orientated coding” created better coding structures that had fewer bugs, but the complexity has continued to grow.
I always recommend the “keep it simple” approach which has served me well.
I see examples of these new approaches on other forums and I do wonder what sort of problems the modern Fortran solves. I often think all they produce is a useless complex mess with no significant outcome. Often there appear to be a simple alternative data structure that could achieve the same result.
I am not aware of where this new complexity is being used. The achievements of Fortran since the 60’s in engineering have been huge, without these complex additions, while most recent computing advances appear to be outside the standard, eg vector and parallel processing.
I am sure many may disagree with me, but where are their results.
John |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Mon Dec 07, 2015 1:56 pm Post subject: |
|
|
Being an old fashioned Fortran programmer, I find that the use of derived types is never in my mind at the beginning of a program development. But where I have used them, they have their advantages in copying data, assigning and passing data as an argument. Instead of referring to each individual element in a series of arrays in say a swap type sort, you only have to do the swap with a single short name and array index. It is worth sticking with the idea and it will gradually become more helpful in new programs.
Ian |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Dec 07, 2015 7:19 pm Post subject: |
|
|
Ian, I'm with you!
I'm finding as I update old code or add new code that the derived types can make the handling of data almost trivial. Also, the ability to initialize each data item in the type individually to what it needs to be when it is created has allowed a great freedom.
While it is not the be-all and end-all, it is useful, just as keeping data in separate named items is sometimes most efficient, either from the coding or the maintenance of the code. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Dec 08, 2015 12:26 am Post subject: |
|
|
I use derived types for data structures. One approach I have found useful is to define parameters for initialisation, such as "zero" or "one". This simplifies initiating all the different types of elements of the type. eg: Code: | TYPE COMMODITY_RECORD
integer*4 terminal
integer*4 brand_id
real*4 tonnage
real*4 fines_fr
integer*4 fines_id
integer*4 sustained_rate
integer*4 gross_rate
integer*4 no_direct
character brand_name*10
END TYPE COMMODITY_RECORD
!
type (Commodity_Record), parameter :: &
Commodity_zero = Commodity_record (0, 0, 0., 0., 0, 0, 0, 0, ' ')
!
type (Commodity_Record) Commodity(m$brand)
...
do i = 1,m$brand
Commodity(i) = Commodity_zero
end do
! or
Commodity = Commodity_zero
|
|
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Tue Dec 08, 2015 1:28 pm Post subject: |
|
|
Probably a good idea to stick the keyword "SEQUENCE" in the definition.
Is there an intrinsic function to find the length in bytes of a derived type?
Ian
"The compiler is free to store the constituents of a derived type how it chooses. To force the derived type to be stored contiguously, use the sequence keyword." |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Dec 08, 2015 2:23 pm Post subject: |
|
|
Ian,
Where did you get the quote from? Quote: | The compiler is free to store the constituents of a derived type how it chooses. To force the derived type to be stored contiguously, use the sequence keyword. |
If you transfer a derived type as a subroutine argument, what assumptions can you make about how it is transferred. Surely, with limited assumptions there will be less efficiency in the transfer. I presume that the derived type definition should be in a use module. I tend to declare all my derived types in a module and not use them as routine arguments.
Determining the length of arrays or derived type is an interesting problem, especially if you want the length in bytes.
SIZE will give the length of an intrinsic type array as elements of the array (section), but not derived types.
There is a F2008 intrinsic STORAGE_SIZE which returns the bit length of an array of any type. Not sure if this includes both intrinsic and derived types. It would be a useful addition to FTN95. Storage_size reports the memory size, so if it includes derived types, it also accounts for alignment spacing of derived type elements.
Ifort provides a function SIZEOF which returns the byte size of an array of any type. Again, not sure if this includes both intrinsic and derived types. I think this would be a very useful addition to FTN95.
You can approach this by using the LOC function, which also I could not find listed in the Fortran standards I have.
It is a shame that the byte size of any nameable group can not be sized in bytes. Something a Fortran user wants!
Lately I have been lobbying Silverfrost to include more functions in SALFLIBC.DLL. I would like more information functions, such as SIZEOF or Compiler_Version or DOT_PRODUCT_SSE etc, which do not require new coding structures that are in F03 or F08.
John |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Dec 08, 2015 8:43 pm Post subject: |
|
|
I found that first link Ian when I did my first googling on the subject.
What sounded like it might an 'interesting' (and probably befuddling for me ) application for Derived Types was this paragraph .....
Quote: | The real power of derived types comes with the ability to choose bewteen functions (or subroutines) based on the type of their arguments. Different functions can be called by the same name, depending on whether the argument type is real, integer,or even a derived type. Intrinsic Fortran routines have always had this ability, the simplest example being choosing between single and double precision versions of the function. Now it can be extended to user's routines and defined data types as well. See the example in the section on intefaces for subroutines . |
except that the link 'interfaces for subroutines', stated as containing an examples, just takes you to the same page !!!
Any idea where that section is ? (attempts to backtrack in the URL tree having failed me).[/b] |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Dec 09, 2015 11:12 pm Post subject: |
|
|
I don't know if this is the right thread but someone was asking how to get the size of a user defined type. Here is one way...
Code: | type atype
integer k
double precision x
end type
type(atype)::a
integer sizeof
inquire(iolength=sizeof) a
print*, sizeof
end
|
|
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Thu Dec 10, 2015 8:36 am Post subject: |
|
|
Paul,
Thanks for that.
Ian |
|
Back to top |
|
|
|