array valued functions
Author Message
array valued functions

Quote:

> > i am trying to write a simple function that takes two arrays
> > and returns me their sum vector. i want to do it using a function
> > and not a subroutine. I tried the following

> > FUNCTION VECP(A, B)

> You need a RESULT clause in order to pass back the sum to
> the invoking statement.
> e,g, FUNCTION VECP (A, B) RESULT (VECP)

> > IMPLICIT DOUBLE PRECISION (A - Z)

> > DIMENSION A(3), B(3)
> > DOUBLE PRECISION, DIMENSION(3) :: VECP

> > VECP(1) = A(1)+B(1)
> > VECP(2) = A(2)+B(2)
> > VECP(3) = A(3)+B(3)

> > RETURN
> > END

Above is wrong..
You can not use function's name as target of the result clause
(at least using CVF compiler you cant).
Plus you are wrong that a result clause is needed, to make above
compile ok, just eliminate the result clause.

As a fortran book author I'm surprised you didnt tell him to just use
C = A + B  without the use of a function,
even PL/I allows direct array math syntax, right?

Tue, 13 Dec 2005 19:36:19 GMT
array valued functions

Quote:

> > > i am trying to write a simple function that takes two arrays
> > > and returns me their sum vector. i want to do it using a function
> > > and not a subroutine. I tried the following

> > > FUNCTION VECP(A, B)

> > You need a RESULT clause in order to pass back the sum to
> > the invoking statement.
> > e,g, FUNCTION VECP (A, B) RESULT (VECP)

Oops, hadn't noticed that VECP is name of function.

Quote:
> > > IMPLICIT DOUBLE PRECISION (A - Z)

> > > DIMENSION A(3), B(3)
> > > DOUBLE PRECISION, DIMENSION(3) :: VECP

> > > VECP(1) = A(1)+B(1)
> > > VECP(2) = A(2)+B(2)
> > > VECP(3) = A(3)+B(3)

> > > RETURN
> > > END

> Above is wrong..

> I'm surprised you didnt tell him to just use
> C = A + B  without the use of a function,

he wanted a function that returned an array result.

Quote:
> even PL/I allows direct array math syntax, right?

It has, for 38 years.

Tue, 13 Dec 2005 22:10:16 GMT
array valued functions

Quote:

> > > > i am trying to write a simple function that takes two arrays
> > > > and returns me their sum vector. i want to do it using a
function
> > > > and not a subroutine. I tried the following

> > > > FUNCTION VECP(A, B)

> > > You need a RESULT clause in order to pass back the sum to
> > > the invoking statement.
> > > e,g, FUNCTION VECP (A, B) RESULT (VECP)

> Oops, hadn't noticed that VECP is name of function.

> > > > IMPLICIT DOUBLE PRECISION (A - Z)

> > > > DIMENSION A(3), B(3)
> > > > DOUBLE PRECISION, DIMENSION(3) :: VECP

> > > > VECP(1) = A(1)+B(1)
> > > > VECP(2) = A(2)+B(2)
> > > > VECP(3) = A(3)+B(3)

> > > > RETURN
> > > > END

> > Above is wrong..

> > I'm surprised you didnt tell him to just use
> > C = A + B  without the use of a function,

> he wanted a function that returned an array result.

A nice try implying you have corrected the poster's function, but when
you remove your erroneous result clause, we are left with poster's
ORIGINAL function, which was and is correct..

allocated array result from a function?

Tue, 13 Dec 2005 23:06:23 GMT
array valued functions

...

Quote:
> allocated array result from a function?

(Editors are our friends - especially when posting follow-ups.)
(M\$ editors and IE are not our friends - BECAUSE THEY DON'T
STICK TO FIXED FONT SIZES!!!  {*filter*} THEM!)

I wrestled with this very problem years ago.
After all, if APL can return arbitrary sized
arrays, howcum PL/I can't?  To find the answer,
put yourself in the position of a compiler writer
of that era.  The calling program must know how
much space to allocate for the returned result.
An APL interpreter has little problem with this,
unless it runs out of memory.  I describe PL/I
as semi-interpretive, but the complications of
returning arbitrary sized arrays and structures
are enormous.

I just reread the LRM concerning the RETURNS
attribute, and a flood of (possibly bad) memories
came back about the FORTRAN baggage PL/I got -
namely multiple ENTRY points.  I don't recall
ever using this abomination during my FORT-IV
career (1970-82), but the structured programming
folks (H. Mills et al) made me shudder at the idea
of using that construct in PL/I.  It makes GOTO
and COME FROM look positively friendly. Think of
this compiler writer's horror story:

PUKE: PROCEDURE ( DAMN ) RETURNS ( {*filter*});

DECLARE ( DAMN, {*filter*}) LABEL;

DECLARE  ( DATE, SUBSTR ) BUILTIN;

IF  SUBSTR ( DATE, 5, 2 ) = '01'  THEN
GO TO DAMN;  /* It's payday */
ELSE
RETURN ( DAMN );
/* Who knows what the caller will do? */
END PUKE;

But I digress.  I don't think it's asking too much
of a crisp PL/I designer to figure out how to deal
with a variable sized array at runtime within the
restrictions of the IBM PL/I I learned 30+ years ago.

TRYTHIS:  /* A bit of meaningless nonsense. */
PROCEDURE OPTIONS ( MAIN );

DECLARE  /* A simple structure */
1 DUMBSTUFF  BASED ( WHERE ),
2 ( CALL_COUNT  FIXED BINARY,
NUMBERS( CALLS REFER ( CALL_COUNT )
);
DECLARE  CALLS  FIXED BINARY STATIC INTIAL ( 1 );

DECLARE  MAKE# ( FIXED BINARY ) RETURNS ( POINTER );

DO  CALLS = CALLS TO 100;

PUT SKIP LIST ( MAKE# ( CALLS ) -> DUMBSTUFF );
END;
END TRYTHIS;
*PROCESS
MAKE#: PROCEDURE ( CALLS ) RETURNS ( POINTER );

DECLARE  /* A simple structure */
1 DUMBSTUFF  BASED ( WHERE ),
2 ( CALL_COUNT  FIXED BINARY,
NUMBERS( CALLS REFER ( CALL_COUNT )
);
DECLARE  CALLS  FIXED BINARY;

ALLOCATE  DUMBSTUFF;
DO I = 1 TO CALLS;
NUMBERS(I) = I;
END;

RETURN ( WHERE );
END MAKE#'

Wed, 14 Dec 2005 19:54:05 GMT
array valued functions

Quote:

> ...
> > How about demoing your beloved PL/I's 38yo syntax returning a
> > allocated array result from a function?

> I wrestled with this very problem years ago.

<snip> PL/I code that purports to demo function returning variable
array output but is totally incomprensible to me, (and I bet others
here as well).
How about starting with my simple fortran source below and translate
it?
and
if you do, pls confirm your program ACTUALLY outputs the expected
results as shown.

! --------------------------------
program test
real :: x(3) = [1., 2., 3.]
real :: y(3) = [4., 5., 6.]
write (*,*) sumv(x,y) ! outputs  5.0 7.0 9.0
stop
contains
function sumv(a,b)  result (c)
real :: a(:), b(:), c(size(a))
c = a + b
end function sumv
end program test

Thu, 15 Dec 2005 20:17:29 GMT
array valued functions

Quote:
> <snip> PL/I code that purports to demo function returning variable
> array output but is totally incomprensible to me, (and I bet others
> here as well).
> How about starting with my simple fortran source below and translate
> it?
> Pls use same variable names/etc so everyone can follow your syntax,
> and
> if you do, pls confirm your program ACTUALLY outputs the expected
> results as shown.

Sorry, as I indicated, I checked out of FORTRAN IV in 82.
I have no manual for the alleged FORTRAN posted example,
thus no way to confirm the results.  My basic rule was that
if it didn't run under WATFIV,  it wasn't FORTRAN.

B-)

Fri, 16 Dec 2005 02:34:46 GMT
array valued functions

Quote:

> > <snip> PL/I code that purports to demo function returning variable
> > array output but is totally incomprensible to me, (and I bet
others
> > here as well).
> > How about starting with my simple fortran source below and
translate
> > it?
> > Pls use same variable names/etc so everyone can follow your
syntax,
> > and
> > if you do, pls confirm your program ACTUALLY outputs the expected
> > results as shown.

>   Sorry, as I indicated, I checked out of FORTRAN IV in 82.
>   I have no manual for the alleged FORTRAN posted example,
>   thus no way to confirm the results.  My basic rule was that
>   if it didn't run under WATFIV,  it wasn't FORTRAN.

>   B-)

Note I am not asking you to write ANY fortran, its already been
written,
(see below)..  I am just asking you to write your PL/I function using
it as a guide that can be followed by ANY computer science 101 student
..
expected results,  5.0 7.0 9.0

! --------------------------------
program test
real :: x(3) = [1., 2., 3.]
real :: y(3) = [4., 5., 6.]
write (*,*) sumv(x,y) ! outputs  5.0 7.0 9.0
stop
contains
function sumv(a,b)  result (c)
real :: a(:), b(:), c(size(a))
c = a + b
end function sumv
end program test

Fri, 16 Dec 2005 16:39:17 GMT
array valued functions
Robin continues trying to bail-out his disasterous forray in
comp.lang.fortran posing as a fortran guru.
His latest reply has been shot down by Richard Maine (see below)..

Quote:

> You'll need an expicit interface and a change to the declarations
> of the dummy arguments:--

Yes, the explicit intgerface is needed, as mentioned in other replies
in this thread (at least in mine - though I didn't show code to do
so).

However, changing the dummy arguments to assumed shape is not needed,
and I wouldn't even think of doing it the way robin shows here.  I
generally do prefer assumed shape dummy arguments, but certainly not
like this

Quote:
> FUNCTION VECP(A, B)
>    IMPLICIT NONE
>    REAL, INTENT (IN) :: A(:), B(:)
>    REAL, DIMENSION(3) :: VECP

>    VECP(1) = A(1)+B(1)
>    VECP(2) = A(2)+B(2)
>    VECP(3) = A(3)+B(3)
>    RETURN
> END FUNCTION VECP

Here the dummies are declared assumed shape, but the function result
and the body of the code are hard-wired to specific sizes.  Nothing
good can come of this.  Make declarations agree with the actual usage.
In this case, the actual usage is hard-wired to a size of 3.

If you want to use assumed shape, that's fine, but in that case,
make the function return shape depend on that of the arguments
and make the body loop also do so.

--
Richard Maine

Fri, 16 Dec 2005 17:13:21 GMT
array valued functions

Quote:
> Note I am not asking you to write ANY fortran, its already been
> written,
> (see below)..  I am just asking you to write your PL/I function
using
> it as a guide that can be followed by ANY computer science 101

student

A Comp Sci 101 student who can't RTFM and draw from
the example posted is far too inexperienced and immature
to be dealing with such heady matters.  Try printing out a
table of sines and cosines first.

Sat, 17 Dec 2005 03:38:01 GMT
array valued functions

Quote:

> > Note I am not asking you to write ANY fortran, its already been
> > written,
> > (see below)..  I am just asking you to write your PL/I function
> using
> > it as a guide that can be followed by ANY computer science 101
> student

>   A Comp Sci 101 student who can't RTFM and draw from
>   the example posted is far too inexperienced and immature
>   to be dealing with such heady matters.  Try printing out a
>   table of sines and cosines first.

Typical obfuscation from a pli'er when forced to "put up or shut up"
here.

Sat, 17 Dec 2005 05:29:40 GMT
array valued functions

Quote:

> Robin continues trying to bail-out his disasterous forray in
> comp.lang.fortran posing as a fortran guru.

My approach of showing him how to interface to a function
that uses assumed-shape dummy argument has now been vindicated
by the poster subsequently requesting a book about Fortran.

Date: Sat, 28 Jun 2003 15:52:36 GMT

Quote:

>> You'll need an expicit interface and a change to the declarations
>> of the dummy arguments:--
> Yes, the explicit intgerface is needed, as mentioned in other replies
> in this thread (at least in mine - though I didn't show code to do so).
> However, changing the dummy arguments to assumed shape is not needed,
> and I wouldn't even think of doing it the way robin shows here.

I am certainly not going to illustrate an obsolete and error-prone method
of passing arguments.
Nor an I going to illustrate an inflexible (hard-wired) dummy.
This example illustrates generally how the dummy is linked.
In any case, dummy arguments that are not assumed shape
are not supported in some of the subset compilers.

Quote:
> I generally do prefer assumed shape dummy arguments, but certainly not
> like this
>> FUNCTION VECP(A, B)
>>    IMPLICIT NONE
>>    REAL, INTENT (IN) :: A(:), B(:)
>>    REAL, DIMENSION(3) :: VECP

>>    VECP(1) = A(1)+B(1)
>>    VECP(2) = A(2)+B(2)
>>    VECP(3) = A(3)+B(3)
>>    RETURN
>> END FUNCTION VECP
> Here the dummies are declared assumed shape, but the function result
> and the body of the code are hard-wired to specific sizes.

Please do credit the originator with sufficient nous to
change this code to something general (a loop) when he gets the
basic material to work.

Quote:
>  Nothing
> good can come of this.  Make declarations agree with the actual usage.
> In this case, the actual usage is hard-wired to a size of 3.

Ugh!
The originator was
(a) having trouble with interfacing to the function
(b) experimenting with the arguments & dummies, getting it down to
the basics, to try to get something to work, which is a good approach.
I have made minimum changes to his code to show how the interface is done.
No-one else did that (show how the interface is done)

Quote:
> If you want to use assumed shape, that's fine, but in that case,
> make the function return shape depend on that of the arguments
> and make the body loop also do so.

No doubt the originator will do that once he has the interface
working with the general case, which would be, of course, non-"hard-wired"
array sizes.

Quote:
> --
> Richard Maine

======================================================
Quote:
> His latest reply has been shot down by Richard Maine (see below)..

> > You'll need an expicit interface and a change to the declarations
> > of the dummy arguments:--

> Yes, the explicit intgerface is needed, as mentioned in other replies
> in this thread (at least in mine - though I didn't show code to do
> so).

> However, changing the dummy arguments to assumed shape is not needed,
> and I wouldn't even think of doing it the way robin shows here.  I
> generally do prefer assumed shape dummy arguments, but certainly not
> like this

> > FUNCTION VECP(A, B)
> >    IMPLICIT NONE
> >    REAL, INTENT (IN) :: A(:), B(:)
> >    REAL, DIMENSION(3) :: VECP

> >    VECP(1) = A(1)+B(1)
> >    VECP(2) = A(2)+B(2)
> >    VECP(3) = A(3)+B(3)
> >    RETURN
> > END FUNCTION VECP

> Here the dummies are declared assumed shape, but the function result
> and the body of the code are hard-wired to specific sizes.  Nothing
> good can come of this.  Make declarations agree with the actual usage.
> In this case, the actual usage is hard-wired to a size of 3.

> If you want to use assumed shape, that's fine, but in that case,
> make the function return shape depend on that of the arguments
> and make the body loop also do so.

> --
> Richard Maine

Mon, 19 Dec 2005 08:45:39 GMT

 Page 1 of 1 [ 11 post ]

Relevant Pages