forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

User-Defined TYPES - What Practical Usefulness ... If Any ?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1451
Location: Aerospace Valley

PostPosted: Sat Dec 05, 2015 9:06 pm    Post subject: User-Defined TYPES - What Practical Usefulness ... If Any ? Reply with quote

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 Wink ! LOL ]
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2229
Location: Sydney

PostPosted: Sun Dec 06, 2015 12:16 am    Post subject: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 474
Location: Sunderland

PostPosted: Mon Dec 07, 2015 1:56 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
wahorger



Joined: 13 Oct 2014
Posts: 825
Location: Morrison, CO, USA

PostPosted: Mon Dec 07, 2015 7:19 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2229
Location: Sydney

PostPosted: Tue Dec 08, 2015 12:26 am    Post subject: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 474
Location: Sunderland

PostPosted: Tue Dec 08, 2015 1:28 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2229
Location: Sydney

PostPosted: Tue Dec 08, 2015 2:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 474
Location: Sunderland

PostPosted: Tue Dec 08, 2015 8:02 pm    Post subject: Reply with quote

Quote was from here:
https://courses.physics.illinois.edu/phys466/sp2013/comp_info/derived.html

see also
http://h21007.www2.hp.com/portal/download/files/unprot/fortran/docs/lrm/lrm0038.htm#derived_def
Back to top
View user's profile Send private message Send e-mail
John-Silver



Joined: 30 Jul 2013
Posts: 1451
Location: Aerospace Valley

PostPosted: Tue Dec 08, 2015 8:43 pm    Post subject: Reply with quote

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 Smile ) 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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6568
Location: Salford, UK

PostPosted: Wed Dec 09, 2015 11:12 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
IanLambley



Joined: 17 Dec 2006
Posts: 474
Location: Sunderland

PostPosted: Thu Dec 10, 2015 8:36 am    Post subject: Reply with quote

Paul,
Thanks for that.
Ian
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group