Hello,

Given an array with 10,000 real values, I want to find the median. And
I want to do this about 100,000 times. My current plan is to implement
Quicksort or Merge Sort in Fortran and pick the middle point of the
array to get the median. I was just wondering Fortran already has a
way to do this. I am sure I am not the first person in history to want
the median of a group of values in Fortran. But I cannot find an
intrinsic function called "median".

Any thoughts?

Thanks.
Daniel.

"Daniel Carrera" <dcarrera@gmail.com> wrote in message 
news:d510fdac-68cd-4637-811d-985d58ec0541@40g2000vbn.googlegroups.com...

> Given an array with 10,000 real values, I want to find the median. And
> I want to do this about 100,000 times. My current plan is to implement
> Quicksort or Merge Sort in Fortran and pick the middle point of the
> array to get the median. I was just wondering Fortran already has a
> way to do this. I am sure I am not the first person in history to want
> the median of a group of values in Fortran. But I cannot find an
> intrinsic function called "median".

I wrote up some stuff a while back:

http://home.comcast.net/~kmbtib/Fortran_stuff/order_stat.i90
http://home.comcast.net/~kmbtib/Fortran_stuff/order_stat_test.f90

Can't recall whether it's exactly what you need, but it's faster
than sorting, anyhow.  Write back if you encounter problems.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <ibh78q$l28$1@news.eternal-september.org>,
James Van Buskirk <not_valid@comcast.net> wrote:
>"Daniel Carrera" <dcarrera@gmail.com> wrote in message 
>news:d510fdac-68cd-4637-811d-985d58ec0541@40g2000vbn.googlegroups.com...
>
>> Given an array with 10,000 real values, I want to find the median. And
>> I want to do this about 100,000 times. My current plan is to implement
>> Quicksort or Merge Sort in Fortran and pick the middle point of the
>> array to get the median. I was just wondering Fortran already has a
>> way to do this. I am sure I am not the first person in history to want
>> the median of a group of values in Fortran. But I cannot find an
>> intrinsic function called "median".
>
>I wrote up some stuff a while back:
>
>http://home.comcast.net/~kmbtib/Fortran_stuff/order_stat.i90
>http://home.comcast.net/~kmbtib/Fortran_stuff/order_stat_test.f90
>
>Can't recall whether it's exactly what you need, but it's faster
>than sorting, anyhow.  Write back if you encounter problems.

There is a much faster algorithm, incidentally.

1) Estimate a range around its value using a small, fixed sample.

2) Pass through the array, copying the values within the range,
and counting those to the left and right.

3) Repeat on the subset if the counts were good, and using the
fact that you now know which side it was if not.

4) Repeat until the sample is small enough to sort.

You can use a limited size array for the subset, incidentally,
and do a modification of the above if you run out of space.

The theory of this is standard statistics.

I have the code somewhere, but wouldn't be able to find it,
because I can't even rememember which decade I did it in and
scanning through all my archives (in half a dozen formats) is
too time-consuming.  Sorry.


Regards,
Nick Maclaren.

nmm1@cam.ac.uk wrote:
(snip)
>>"Daniel Carrera" <dcarrera@gmail.com> wrote in message 
>>news:d510fdac-68cd-4637-811d-985d58ec0541@40g2000vbn.googlegroups.com...

>>> Given an array with 10,000 real values, I want to find the median. 
(snip)

> There is a much faster algorithm, incidentally.

Is that the one in Knuth, "The Art of Computer Programming", my
guess is volume 3?   It doesn't sound familiar, but I could have
forgotten how it went.
 
> 1) Estimate a range around its value using a small, fixed sample.
 
> 2) Pass through the array, copying the values within the range,
> and counting those to the left and right.
 
> 3) Repeat on the subset if the counts were good, and using the
> fact that you now know which side it was if not.
 
> 4) Repeat until the sample is small enough to sort.
 
> You can use a limited size array for the subset, incidentally,
> and do a modification of the above if you run out of space.
 
> The theory of this is standard statistics.
 
> I have the code somewhere, but wouldn't be able to find it,
> because I can't even rememember which decade I did it in and
> scanning through all my archives (in half a dozen formats) is
> too time-consuming.  Sorry.

-- glen

In article <ibhmgo$b1q$1@news.eternal-september.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>
>>>> Given an array with 10,000 real values, I want to find the median. 
>
>> There is a much faster algorithm, incidentally.
>
>Is that the one in Knuth, "The Art of Computer Programming", my
>guess is volume 3?   It doesn't sound familiar, but I could have
>forgotten how it went.

No.  Knuth is not strong on statistical algorithms.  It includes
the one that James Van Buskirk posted.


Regards,
Nick Maclaren.

nmm1@cam.ac.uk wrote:
> In article <ibhmgo$b1q$1@news.eternal-september.org>,
> glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

>>>>> Given an array with 10,000 real values, I want to find the median. 

>>> There is a much faster algorithm, incidentally.

>>Is that the one in Knuth, "The Art of Computer Programming", my
>>guess is volume 3?   It doesn't sound familiar, but I could have
>>forgotten how it went.
 
> No.  Knuth is not strong on statistical algorithms.  

The one in Knuth is supposed to be O(N), which doesn't mean
that it is fastest for any, or even most, sets of input data.

Some of this seems to be in the wikipedia page Selection_algorithm.

The wikipedia page for Median_graph has a reference to Knuth's
volume 4, I believe available on the web, but not in print.

> It includes the one that James Van Buskirk posted.

I don't always read posted links.

-- glen

In article <ibho1g$b1q$3@news.eternal-september.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>
>>>>>> Given an array with 10,000 real values, I want to find the median. 
>
>>>> There is a much faster algorithm, incidentally.
>
>>>Is that the one in Knuth, "The Art of Computer Programming", my
>>>guess is volume 3?   It doesn't sound familiar, but I could have
>>>forgotten how it went.
> 
>> No.  Knuth is not strong on statistical algorithms.  
>
>The one in Knuth is supposed to be O(N), which doesn't mean
>that it is fastest for any, or even most, sets of input data.

The one I posted is also O(N) with probability one, but with a
much lower factor.  It is very common that replacing a pure
mathematical worst case with a probability zero one produces
a much faster algorithm, that is every bit as reliable in real
use.


Regards,
Nick Maclaren.

Thanks for the help.

Now I know that I need to write my own function. Thanks for the
suggestions for algorithms. I'll try to pick something that I
understand, but is efficient. I have an idea for an algorithm based on
the quicksort / mergesort idea. Probably not as efficient as James'
code, but it should be good enough, and it'll be something I
understand.

Thanks for the help.

Cheers,
Daniel.

On 12.11.2010. 10:52, Daniel Carrera wrote:
> Thanks for the help.
>
> Now I know that I need to write my own function. Thanks for the
> suggestions for algorithms. I'll try to pick something that I
> understand, but is efficient. I have an idea for an algorithm based on
> the quicksort / mergesort idea. Probably not as efficient as James'
> code, but it should be good enough, and it'll be something I
> understand.
>
> Thanks for the help.

Take a look at Michel Olagnon's (who used to frequent clf):

http://www.fortran-2000.com/rank/

In particular, INDMED and VALMED are based on Knuth. I used some
of other Michel's routines, but not these ones.

--
Jugoslav
www.xeffort.com

On Nov 12, 4:02=A0pm, Jugoslav Dujic <jdu...@yahoo.com> wrote:
> Take a look at Michel Olagnon's (who used to frequent clf):
>
> http://www.fortran-2000.com/rank/
>
> In particular, INDMED and VALMED are based on Knuth. I used some
> of other Michel's routines, but not these ones.

Thanks. I'll take a look at VALMED. In fact, I have a question
already. VALMED starts with:

Recursive Function D_valmed (XDONT) Result (res_med)

I thought that function definitions always needed a return type like
"real function foo()". When I compile my own code with gfortran it
always complains if I don't include a return type, but Michel's module
compiles just fine the way it is. What's Michel doing that allows him
to get away with a function without a return type?

Anyway, I'll try to understand how Michel's code works. I did come up
with a nice, simple algorithm to get the median in O(n log n), and is
fast enough for my purposes (will add ~2.7 mins to a program that runs
8 hours). But I'll probably learn something interesting by looking at
Michel's code.

For reference, my code is below. It sorts an array of real numbers and
is inspired quicksort / mergesort:


real function qmedian(list)
    real, dimension(:), intent(in) :: list
    integer :: n
    real :: dummy

    n =3D size(list)
    dummy =3D rand(1)
    if (mod(n,2) =3D=3D 0) then
        qmedian =3D qmedian_helper(list, n/2)
    else
        qmedian =3D qmedian_helper(list, n/2 + 1)
    end if
end function

real recursive function qmedian_helper(list, q) result(res)
    ! Parameters
    real, dimension(:), intent(in) :: list
    integer, intent(in) :: q

    ! Internal variables
    real, allocatable, dimension(:) :: left, right
    real :: pivot, lmax, lmin
    integer :: n, j

    ! Algorithm
    n =3D size(list)
    call bounds(list, lmin, lmax)
    if (q =3D=3D 1) then
        res =3D lmin
    else if (q =3D=3D n) then
        res =3D lmax
    else
        !!! Split 'list' into two parts and recurse.

        ! Pick a random element from the list.
        pivot =3D list(int(rand(0)*n)+1)

        j =3D count(list <=3D pivot)

        ! The previous conditions should remove corner cases.
        allocate(left(j))
        allocate(right(n-j))

        left =3D pack(list, list <=3D pivot)
        right=3D pack(list, list  > pivot)

        if (j >=3D q) then
            ! Left side contains kth element.
            res =3D qmedian_helper(left, q)
        else
            ! Right side contains kth element.
            res =3D qmedian_helper(right, q-j)
        end if
    end if
end function

subroutine bounds(list, lmin, lmax)
    real, dimension(:), intent(in) :: list
    real, intent(out) :: lmin, lmax
    integer :: n, i

    n =3D size(list)
    lmin =3D list(1)
    lmax =3D list(1)
    do i =3D 2,n
        if (list(i) < lmin) lmin =3D list(i)
        if (list(i) > lmax) lmax =3D list(i)
    end do
end subroutine


Cheers,
Daniel.

Daniel Carrera wrote:
> On Nov 12, 4:02 pm, Jugoslav Dujic <jdu...@yahoo.com> wrote:
>> Take a look at Michel Olagnon's (who used to frequent clf):
>>
>> http://www.fortran-2000.com/rank/
>>
>> In particular, INDMED and VALMED are based on Knuth. I used some
>> of other Michel's routines, but not these ones.
> 
> Thanks. I'll take a look at VALMED. In fact, I have a question
> already. VALMED starts with:
> 
> Recursive Function D_valmed (XDONT) Result (res_med)
> 
> I thought that function definitions always needed a return type like
> "real function foo()". 

I suspect the answer is made clear if you look at the first point under
"programming style" in the above link,

Ian

On Nov 12, 11:47=A0am, Daniel Carrera <dcarr...@gmail.com> wrote:
> On Nov 12, 4:02=A0pm, Jugoslav Dujic <jdu...@yahoo.com> wrote:
>
> > Take a look at Michel Olagnon's (who used to frequent clf):
>
> >http://www.fortran-2000.com/rank/
>
> > In particular, INDMED and VALMED are based on Knuth. I used some
> > of other Michel's routines, but not these ones.
>
> Thanks. I'll take a look at VALMED. In fact, I have a question
> already. VALMED starts with:
>
> Recursive Function D_valmed (XDONT) Result (res_med)
>
> I thought that function definitions always needed a return type like
> "real function foo()". When I compile my own code with gfortran it
> always complains if I don't include a return type, but Michel's module
> compiles just fine the way it is. What's Michel doing that allows him
> to get away with a function without a return type?

Removing the large comment from Michel's code, I finds
the first 3 lines:

Recursive Function D_valmed (XDONT) Result (res_med)
      Real (kind=3Dkdp), Dimension (:), Intent (In) :: XDONT
      Real (kind=3Dkdp) :: res_med

The return type is declared in line 3.

--
steve

Daniel Carrera <dcarrera@gmail.com> wrote:

> Recursive Function D_valmed (XDONT) Result (res_med)
> 
> I thought that function definitions always needed a return type like
> "real function foo()". When I compile my own code with gfortran it
> always complains if I don't include a return type, but Michel's module
> compiles just fine the way it is. What's Michel doing that allows him
> to get away with a function without a return type?

He presumably declares the type later in the code in a separate
statement. Not only is that allowed, it is what I prefer and recommend.
There can be problems with declaring the type directly on the function
statement; it works in most cases, but not all of them. Declaring the
type in a separate type declaration statement works in *ALL* cases. I
prefer to do things that work all the time so that I don't need to worry
about checking when I have crossed the boundary between the cases that
work and the ones that don't.

Also note that when you declare the result variable to have a separate
name, it is the result variable whose type gets declared - not the
function.

As an aside, no, you don't have to explicitly declare the type. If you
don't declare the type, implicit typing applies, just as with any other
variable. I disrecommend the use of implicit typing, and if you use
impkicit none, the compiler will bitch about it, but it is allowed. If
your compiler complains when you omit the type, then probably you are
using implicit none (which I do recommend). Either that or you are doing
something that is incompatible with the implicit type. Be aware that
implicit typing does *NOT* mean that an entity has no type; it just
means that the type is determined by the implicit typing rules instead
of by an explicit type declaration. I wouldn't mention this except that
I wonder why you would ever be trying to write code that doesn't declare
the return type and also isn't deliberately using implicit typing; the
only reason I can think of (other than just an accident) is that one
might think that failing to explicitly declare the type somehow left it
generic.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Nov 12, 8:59=A0pm, steve <kar...@comcast.net> wrote:
> On Nov 12, 11:47=A0am, Daniel Carrera <dcarr...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 12, 4:02=A0pm, Jugoslav Dujic <jdu...@yahoo.com> wrote:
>
> > > Take a look at Michel Olagnon's (who used to frequent clf):
>
> > >http://www.fortran-2000.com/rank/
>
> > > In particular, INDMED and VALMED are based on Knuth. I used some
> > > of other Michel's routines, but not these ones.
>
> > Thanks. I'll take a look at VALMED. In fact, I have a question
> > already. VALMED starts with:
>
> > Recursive Function D_valmed (XDONT) Result (res_med)
>
> > I thought that function definitions always needed a return type like
> > "real function foo()". When I compile my own code with gfortran it
> > always complains if I don't include a return type, but Michel's module
> > compiles just fine the way it is. What's Michel doing that allows him
> > to get away with a function without a return type?
>
> Removing the large comment from Michel's code, I finds
> the first 3 lines:
>
> Recursive Function D_valmed (XDONT) Result (res_med)
> =A0 =A0 =A0 Real (kind=3Dkdp), Dimension (:), Intent (In) :: XDONT
> =A0 =A0 =A0 Real (kind=3Dkdp) :: res_med
>
> The return type is declared in line 3.

Interesting. I didn't know you could do that. I was beginning to think
that he was relying on implicit types in some way. I notice that he
doesn't use "IMPLICIT NONE".

Thanks. I learned something new today.

Daniel.

On Nov 12, 9:05=A0pm, nos...@see.signature (Richard Maine) wrote:
> He presumably declares the type later in the code in a separate
> statement. Not only is that allowed, it is what I prefer and recommend.

Yes, he does. I didn't realize that was possible until Steve pointed
it out.


> There can be problems with declaring the type directly on the function
> statement; it works in most cases, but not all of them. Declaring the
> type in a separate type declaration statement works in *ALL* cases. I
> prefer to do things that work all the time so that I don't need to worry
> about checking when I have crossed the boundary between the cases that
> work and the ones that don't.

Sounds reasonable. I'm surprised that declaring the type on the
function statement can fail. Can you give me an example? Anyway, I
certainly want to use methods that work all the time.


> If your compiler complains when you omit the type, then probably you are
> using implicit none (which I do recommend). Either that or you are doing
> something that is incompatible with the implicit type.

Yes, I always use implicit none. I only have a few weeks knowledge of
Fortran 95, but I learned to use implicit none from the very
beginning. Implicit typing scares me. I'm surprised that Michael
doesn't use implicit none.


> I wouldn't mention this except that
> I wonder why you would ever be trying to write code that doesn't declare
> the return type and also isn't deliberately using implicit typing; the
> only reason I can think of (other than just an accident) is that one
> might think that failing to explicitly declare the type somehow left it
> generic.


It was just an accident. I just forgot to enter the type once and saw
the compiler error. I just "understood" that every function needs a
return type, and I was surprised when I didn't see one in Michael's
code. I never thought of implicit typing (a concept that still seems
very odd to me).

Cheers,
Daniel.

Daniel Carrera <dcarrera@gmail.com> wrote:
> On Nov 12, 9:05�pm, nos...@see.signature (Richard Maine) wrote:
>> He presumably declares the type later in the code in a separate
>> statement. Not only is that allowed, it is what I prefer and recommend.
 
> Yes, he does. I didn't realize that was possible until Steve pointed
> it out.
 
>> There can be problems with declaring the type directly on the function
>> statement; it works in most cases, but not all of them. Declaring the
>> type in a separate type declaration statement works in *ALL* cases. I
>> prefer to do things that work all the time so that I don't need to worry
>> about checking when I have crossed the boundary between the cases that
>> work and the ones that don't.
 
> Sounds reasonable. I'm surprised that declaring the type on the
> function statement can fail. Can you give me an example? Anyway, I
> certainly want to use methods that work all the time.

The separate return variable is required for direct recursion.
(When a function calls itself directly.)  Inside a function without
a separate return variable, either declared on the FUNCTION statement
or in a separate statement, the function name is a variable, and
not a function reference.

-- glen

Daniel Carrera <dcarrera@gmail.com> wrote:

> On Nov 12, 9:05 pm, nos...@see.signature (Richard Maine) wrote:

> > There can be problems with declaring the type directly on the function
> > statement; it works in most cases, but not all of them. Declaring the
> > type in a separate type declaration statement works in *ALL* cases. I
> > prefer to do things that work all the time so that I don't need to worry
> > about checking when I have crossed the boundary between the cases that
> > work and the ones that don't.
> 
> Sounds reasonable. I'm surprised that declaring the type on the
> function statement can fail. Can you give me an example? Anyway, I
> certainly want to use methods that work all the time.

Looking at the code in question, I see that it isn't actualy too far
from the main case that I think fails. Basically, the problems come from
ordering requirements. The function statement is always the first
statement in the function; there are no exceptions to that.

There are some things that you can't use until after the statement that
defines them. If you want to use any of those things on the function
statement, there can be a problem in that the function statement is not
likely to be after the statement where they are defined.

A derived type is one of those things. Normally you can't use a derived
type until after its definition. I think (not worth checking, but I
think it is right) that a special-case exception was made for using a
derived type in a function statement just in order to allow it. I don't
tend to like such special cases and I'd have probably voted against
making one for this (don't recall whether I ever got a chance to make
such a vote - might have). Special cases tend to grow as one discovers
that you didn't catch quite everything. Indeed, this special case didn't
catch everything.

I think the missing case is type parameters. One often (and preferably)
specifies type parameter values using named constants. I do no think
there is a simillar exception to allow using a named constant in a
function statement before its definition. So if you try to do something
like

  real(my_kind) function f(x)
    use module_with_a_definition_of_my_kind
    ...

I think you are out of luck. It is possible that I've gotten confused on
the details and that this particular case works. But if it isn't exactly
this one, it is something simillar. One of the advatanges of doing the
type declararation in a separate statement is that I don't actually have
to keep track of the fine points about exactly which cases work.

Posted excerpts of the posted code do show that it uses a named constant
for a kind type parameter, so it is at least close to this case. I don't
see a USE in the posted extract though, so perhaps the kind type
parameter might be accessed via host association. That would be a case
that was ok.... well as long as it wasn't an interface body.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Nov 12, 10:21=A0pm, nos...@see.signature (Richard Maine) wrote:
> A derived type is one of those things. Normally you can't use a derived
> type until after its definition...
>
> I think the missing case is type parameters. One often (and preferably)
> specifies type parameter values using named constants. I do no think
> there is a simillar exception to allow using a named constant in a
> function statement before its definition. So if you try to do something
> like
>
> =A0 real(my_kind) function f(x)
> =A0 =A0 use module_with_a_definition_of_my_kind
> =A0 =A0 ...
>
> I think you are out of luck.


I just found another example. Suppose you want a function that returns
an array:

    function myfunc() result(res)
        real, dimension(3) :: res
        res =3D (/ 2.3, 2.4, 2.5 /)
    end function

This compiles an runs correctly. But when I tried move the type
declaration to the function definition, the compilation failed.

Cheers,
Daniel.

Daniel Carrera <dcarrera@gmail.com> wrote:

> I just found another example. Suppose you want a function that returns
> an array:
> 
>     function myfunc() result(res)
>         real, dimension(3) :: res
>         res = (/ 2.3, 2.4, 2.5 /)
>     end function
> 
> This compiles an runs correctly. But when I tried move the type
> declaration to the function definition, the compilation failed.

Good point, thought I'll make a minor terminology correction. You
actually can still put the type into the function statement. You just
can't put the dimension attribute there. The dimension is not part of
the type even though you normally put it in the type declaration
statement; it is an attribute.

You can do (and I just checked to make sure that I hadn't missed
something - worked fine).

    real function myfunc() result(res)
        dimension :: res(3)
        res = (/ 2.3, 2.4, 2.5 /)
    end function

I do not recommend that at all. I personally find it abominable. But it
is standard conforming.

Now that you mention attributes, that reminds me that things like the
pointer attribute have simillar issues in not being specifiable on the
function statement. But I don't even want to mention that it is a
possibility for a function to return a pointer because that might prompt
someone to write such functions, which I advise against. Pretend I
didn't say anything. :-)

Functions that return allocatables are a much better example in that I
think they can be good ideas.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Hi, I didn't read everything above.
But a search did not find the term "partial".
IMHO, quantiles, median belongs to it, are fastest found with "partial
sorting".
"Partial sorting" means that the data are not fully sorted, it is only
sorted so far that all smaller values are before the median and all
larger
values are behind, but they are not exactly sorted.
There are good algorithms available if you just look for
"partial sorting".
Wolfgang

On Nov 12, 7:54=A0pm, nos...@see.signature (Richard Maine) wrote:
> Daniel Carrera <dcarr...@gmail.com> wrote:
> > I just found another example. Suppose you want a function that returns
> > an array:
>
> > =A0 =A0 function myfunc() result(res)
> > =A0 =A0 =A0 =A0 real, dimension(3) :: res
> > =A0 =A0 =A0 =A0 res =3D (/ 2.3, 2.4, 2.5 /)
> > =A0 =A0 end function
>
> > This compiles an runs correctly. But when I tried move the type
> > declaration to the function definition, the compilation failed.
>
> Good point, thought I'll make a minor terminology correction. You
> actually can still put the type into the function statement. You just
> can't put the dimension attribute there. The dimension is not part of
> the type even though you normally put it in the type declaration
> statement; it is an attribute.
>
> You can do (and I just checked to make sure that I hadn't missed
> something - worked fine).
>
> =A0 =A0 real function myfunc() result(res)
> =A0 =A0 =A0 =A0 dimension :: res(3)
> =A0 =A0 =A0 =A0 res =3D (/ 2.3, 2.4, 2.5 /)
> =A0 =A0 end function
>
> I do not recommend that at all. I personally find it abominable. But it
> is standard conforming.
>
> Now that you mention attributes, that reminds me that things like the
> pointer attribute have simillar issues in not being specifiable on the
> function statement. But I don't even want to mention that it is a
> possibility for a function to return a pointer because that might prompt
> someone to write such functions, which I advise against. Pretend I
> didn't say anything. :-)
>
> Functions that return allocatables are a much better example in that I
> think they can be good ideas.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

On 11/12/2010 09:30 PM, Daniel Carrera wrote:
> On Nov 12, 9:05 pm, nos...@see.signature (Richard Maine) wrote:
>> He presumably declares the type later in the code in a separate
>> statement. Not only is that allowed, it is what I prefer and recommend.
>
> Yes, he does. I didn't realize that was possible until Steve pointed
> it out.
>
>
>> There can be problems with declaring the type directly on the function
>> statement; it works in most cases, but not all of them. Declaring the
>> type in a separate type declaration statement works in *ALL* cases. I
>> prefer to do things that work all the time so that I don't need to worry
>> about checking when I have crossed the boundary between the cases that
>> work and the ones that don't.
>
> Sounds reasonable. I'm surprised that declaring the type on the
> function statement can fail. Can you give me an example? Anyway, I
> certainly want to use methods that work all the time.
>
>
>> If your compiler complains when you omit the type, then probably you are
>> using implicit none (which I do recommend). Either that or you are doing
>> something that is incompatible with the implicit type.
>
> Yes, I always use implicit none. I only have a few weeks knowledge of
> Fortran 95, but I learned to use implicit none from the very
> beginning. Implicit typing scares me. I'm surprised that Michael
> doesn't use implicit none.
>

Well, I write a lot of quick and dirty programs, but when it is code 
that I want to keep or publish, I do check for undeclared variables.
In the case of the sorting and ranking routines, I compiled them with an 
F compiler, that enforces implicit none, so everything is declared.

Regarding the way declarations are arranged, some features come from the 
fact that I used a pre-processor to build the various type versions of 
the routines, by lack of a suitable mechanism in the language (at least 
at that time, I don't know if something has appeared now).

The code looked at first like:
Module m_mrgrnk
Integer, Parameter :: kdp = selected_real_kind(15)
public :: mrgrnk
private :: kdp
private :: R_mrgrnk, I_mrgrnk, D_mrgrnk
interface mrgrnk
   module procedure D_mrgrnk, R_mrgrnk, I_mrgrnk
end interface mrgrnk
contains

Subroutine D_mrgrnk (XDONT, IRNGT)
$define MYTYPE "Real (kind=kdp)"
$include "mrgrnk.inc"
End Subroutine D_mrgrnk

Subroutine R_mrgrnk (XDONT, IRNGT)
$define MYTYPE "Real"
$include "mrgrnk.inc"
End Subroutine R_mrgrnk

Subroutine I_mrgrnk (XDONT, IRNGT)
$define MYTYPE "Integer"
$include "mrgrnk.inc"
End Subroutine I_mrgrnk
End Module m_mrgrnk

On 11/12/2010 04:02 PM, Jugoslav Dujic wrote:
>
> On 12.11.2010. 10:52, Daniel Carrera wrote:
>> Thanks for the help.
>>
>> Now I know that I need to write my own function. Thanks for the
>> suggestions for algorithms. I'll try to pick something that I
>> understand, but is efficient. I have an idea for an algorithm based on
>> the quicksort / mergesort idea. Probably not as efficient as James'
>> code, but it should be good enough, and it'll be something I
>> understand.
>>
>> Thanks for the help.
>
> Take a look at Michel Olagnon's (who used to frequent clf):
>
> http://www.fortran-2000.com/rank/
>
> In particular, INDMED and VALMED are based on Knuth. I used some
> of other Michel's routines, but not these ones.
>

I programmed Knuth's algorithm for the sake of sport, but in practice it 
is so complex that you would have to go to huge values of N to see some 
advantage over the simple pivoting strategy.

In article <8kc96tFfv4U1@mid.individual.net>,
Michel Olagnon  <molagnon@ifremer-a-oter.fr> wrote:
>
>I programmed Knuth's algorithm for the sake of sport, but in practice it 
>is so complex that you would have to go to huge values of N to see some 
>advantage over the simple pivoting strategy.

That is true, but the statistical one is enough simpler and faster
that you start to see gains at quite low values - if I recall, it's
about 20-25.


Regards,
Nick Maclaren.