Neil,
On Thu, Jun 7, 2012 at 7:42 AM, Neil Carlson <[log in to unmask]> wrote:
> Ondřej,
>
> You've got a long section section on callbacks and the associated
> 'type casting'. It's useful to see, in order to contrast and compare,
> the different ways it _could_ be done, but you've left out what is
> arguably the 'best' way to do this in modern Fortran.
>
> To adapt your example of an integration method, this would look
> something like this.
>
> module integrals
>
> use types, only: dp
> implicit none
> private
>
> public :: integrand, simpson
>
> ! User extends this type
> type, abstract :: integrand
> contains
> procedure(func), deferred :: eval
> end type
>
> abstract interface
> function func(this, x) result(fx)
> import :: integrand, dp
> class(integrand) :: this
> real(dp), intent(in) :: x
> real(dp) :: fx
> end function
> end interface
>
> contains
>
> real(dp) function simpson(f, a, b) result(s)
> class(integrand) :: f
> real(dp), intent(in) :: a, b
> s = ((b-a)/6) * (f%eval(a) + 4*f%eval((a+b)/2) + f%eval(b))
> end function
>
> end module
>
> The abstract type prescribes exactly what the integration routine
> needs, namely a method to evaluate the function, but imposes nothing
> else on the user. The user extends this type, providing a concrete
> implementation of the eval type bound procedure and adding necessary
> context data as components of the extended type.
>
> Here's your usage example adapted to this better method:
>
> module example_usage
>
> use types, only: dp
> use integrals, only: integrand, simpson
> implicit none
> private
>
> public :: foo
>
> type, extends(integrand) :: my_integrand
> real(dp) :: a, k
> contains
> procedure :: eval => f
> end type
>
> contains
>
> function f(this, x) result(fx)
> class(my_integrand) :: this
> real(dp), intent(in) :: x
> real(dp) :: fx
> fx = this%a*sin(this%k*x)
> end function
>
> subroutine foo(a, k)
> real(dp) :: a, k
> type(my_integrand) :: my_f
> my_f%a = a
> my_f%k = k
> print *, simpson(my_f, 0.0_dp, 1.0_dp)
> print *, simpson(my_f, 0.0_dp, 2.0_dp)
> end subroutine
>
> end module
Thanks a lot for this approach! It took me longer but finally
I found time and put your example into the webpages:
http://fortran90.org/src/best-practices.html#vii-object-oriented-approach
(You might need to refresh your browser to see the changes.)
For now I just added it as a section VII in there (and added
your name into Contributors, if it's ok with you). This is really
cool that you can do this OO style in Fortran now, I didn't know about that.
I tried it in my gfortran 4.6 and it works great.
I don't know whether this, or some other approach is the "best".
The advantage of this approach is that this is how one would do it in
C++ or Python. One possible disadvantage is that it might be harder
to read and learn
how to use it --- one of the main advantages of Fortran is that it is easy
to learn and a working scientist or engineer can quickly grasp it and
get things done. Then there is also the question of run-time performance,
I don't know which approach is the fastest.
So for now I'll leave it there as it is, so that at least people know about
the options. Later it'd be nice to refactor this section a little bit,
possibly adding C++ and C examples side by side.
>
> A second general comment about the website. It would appear to present
> itself as a consensus view of the Fortran community (especially given
> the domain name.) Until that time it actually does, I'd suggest making
> it clear that you are the author and that the content really reflects
> your views on the topic. Nevertheless, I think that websites like this
> would be immensely useful to the community, and I applaud you for your
> effort.
Thanks for the encouragement, and you are right about the consensus. So I've
added a section "About": http://fortran90.org/src/about.html,
as the first link in the table of contents at the front page. Please
let me know if you think it is ok and clear now, or whether
I should clarify it more.
Thanks,
Ondrej
|