On Mon, 2010-01-04 at 17:21 -0800, Greenberg, Naomi wrote:
> I found this example of doing polymorphism in Fortran very
> interesting. My question is whether it is more or less efficient than
> "traditional" programming where one has a separate routine to add 2
> vectors and a vector with a scalar. Are we sacrificing any efficiency
> by creating generic type bound procedures?
For nonpolymorphic objects, type-bound procedures, generic or not, are
resolved at compile time, so being generic don't impose a run-time
penalty.
If the object is polymorphic, however, there might be a run-time cost to
select the correct procedure depending on the dynamic type. This is
orthogonal to whether the binding is generic or specific.
For specific bindings, there is a set of procedures from which to select
at run time, depending upon the dynamic type.
For generic bindings, there is a set of procedures for each specific
resolution form the generic set, giving the same set of procedures as
you would have had if you had mentioned the correct specific binding in
the reference, instead of the generic one.
So generic bindings never introduce an extra run-time cost compared to
specific bindings.
> Thank you,
> Naomi Greenberg
> ________________________________________
> From: Fortran 90 List [[log in to unmask]] On Behalf Of Bill Long [[log in to unmask]]
> Sent: Thursday, December 31, 2009 11:34 AM
> To: [log in to unmask]
> Subject: Re: Generic type bound procedures
>
> Jim Xia wrote:
> >
> > Hi
> >
> >
> > This is an illegal code at best. And it doesn't use generic type-bound
> > procedures at all. A correct generic type-bound would be something look
> > like the following in F2003 way
> >
> > module generic_procedure_module_my
> >
> > type :: vector
> > real :: x
> > real :: y
> > contains
> > procedure, pass :: vector_plus_vector
> > procedure, pass :: vector_plus_scalar
> > generic :: add => vector_plus_vector, vector_plus_scalar
> > end type vector
> >
> > contains
> >
> > function vector_plus_vector(v1, v2) result(v3)
> > class(vector), intent(in) :: v1, v2
> > type(vector) :: v3
> >
> > v3%x = v1%x + v2%x
> > v3%y = v1%y + v2%y
> >
> > end function vector_plus_vector
> >
> > function vector_plus_scalar(v1, s) result(v3)
> > class(vector), intent(in) :: v1
> > real, intent(in) :: s
> > type(vector) :: v3
> >
> > v3%x = v1%x + s
> > v3%y = v1%y + s
> >
> > end function vector_plus_scalar
> >
>
> Thanks, Jim, for fixing the code. With the addition of
>
> end module
>
> at the end, this compiles with the Cray compiler.
>
> >
> >
> > If you'd like to stick to F95, then remove the type bound procedure "add".
>
> And also the 'contains' statement in the type definition, and the
> 'procedure,pass :: ...' statements. And the CLASS statements in the
> function definitions. All of this was new on f03. If you want an f95
> code, create a separate generic interface for 'add' and change 'class'
> to 'type' in the function definitions. As vendors have gradually added
> f03 (and even some f08 proposed) features to their compilers, we tend to
> forget how primitive pure f95 really was.
>
> Cheers,
> Bill
>
>
>
>
>
> --
> Bill Long [log in to unmask]
> Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4732 (20091231) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
|