Jaehoon Seol writes:
 > Hi,there. I have a function which has the following
 > interface;
 > 
 >         function testFn(xx)
 >            implicit none
 >            real,dimension(:) :: xx
 >            real,dimension(size(xx)) :: testFn
 > When I called this function in the following ways
 > 
 >        value = testFn(1.0) 
 >        v1 = 1.0
 >        value = testFn(v1)  ! v1 has the type real
 > 
 > compiler didn't compile this. I thought that constant is
 > compatible with any array. I wonder how the make intrisic
 > function exp() can handle this kind of situation without
 > using an array of size 1 or multiple definition of the 
 > function. Any help will be appreciated.Thanks.

Three things.

1. I assume you have an explicit interface.  It is required for
   procedures with assumed shape dummy args (which you have).
   If you don't have an explicit interface, you will get all kinds
   of strange errors, varying from system to system.  See many
   threads on the subject.  If I had the time to write up a FAQ
   of technical f90 questions, this would certainly be high on it.

2. But that won't solve yourt problem in this case anyway.  Your
   thought that constants are compatable with arrays in this sense
   is simply wrong.

   F77 (and by inclusion, f90) does have one odd situation in which
   scalars and arrays can get confused, but it doesn't apply to your
   situation.  If you pass an element of an array as an actual
   argument, the dummy argument can be either a scalar or an array
   (if an array, it can't be assumed shape).  This is because f77
   had no way of explicitly indicating an array section - so you just
   passed the starting address, and the standard did (and does) say
   this is ok.

   F95 has a solution, but in f90 there are only 3 approaches that I can
   think of, none really what you want.

    a. As you mentioned, write 2 routines, one for scalars and one for
       vectors.  (And if you want higher ranks also, you'll need one
       for each rank).  You can make these generic if you like.

    b. Write the routine for scalars and use DO loops in the calling
       routine to call it with scalars.  Will certainly work, but
       probably not what you wanted.  Makes the calling code a bit
       verbose for the array case.

    c. Write the routines for arrays and use array constructors to
       put your scalars into size 1 arrays, as in

           x = func( (/ y /) )

       A bit verbose and confusing.  

       Oops.  I forgot, the result of your func is also a size 1
       vector, so its even worse.  You'd have to get the result back
       into a scalar form to put it into x.  Several ways to do that,
       one of which is the sum intrinsic.  Giving

           x = sum( func( (/ y /) ) )

       which is even more verbose and confusing.  Plus, its likely
       inefficient. Also, *WILL NOT WORK* for output arguments.  For
       functions (which "normally" don't have output arguments, you
       are probably ok, but don't forget the caution.

3. You ask about the parallels with f90 intrinsics like exp, which can
   take either array or scalar arguments.  These are known as
   elemental procedures.  In f90, you can't write elemental procedures
   yourself - the only ones are the intrinsics.  F95 does allow you
   to write your own intrinsics.  Don't know whether thats a practical
   answer for you or not.  There are a handfull of f95 compilers out
   now, but not yet very many.

   ALso note that elementals are subject to *VERY* severe constraints,
   which mean that in practice, they better be pretty simple - like
   the intrinsics.  Things like fundamental math functions are good
   candidates.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%