Any suggested workarounds for writing wrappers for functions that areto be passed as arguments?

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> For OS/360 Fortran IV, where ENTRY is listed as an extension.
> (grayed out in the manual), it seems to be partly by design.

That matches my recollection. This was f66 (and earlier) stuff, before
ENTRY was standardized in f77. I seem to recall multiple incompatible
specifications of ENTRY prior to its standardization in f77.

The scheme of saving argument references across calls was one. I also
think I recall a scheme where the arguments to all the entries were the
same, in fact where the syntax didn't even allow you to specify an
argument list. CDC perhaps. Those two schemes are obviously inherently
incompatible. Seems to me I ran into this when trying to port some
pre-f77 code.

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

glen herrmannsfeldt wrote:
> Steve Lionel wrote:
> (snip on ENTRY and the use of dummy variables)
>
>> In some older implementations, it might seem to work
>> "sort-of-magically", but
>> not by design. VAX Fortran, for example, when you called the function
>> would
>> store in a fixed location the addresses of all the arguments and would
>> just
>> reference those locations no matter where you entered the procedure.
>> I saw a
>> lot of programs that depended on this "memory" behavior which then
>> broke when
>> compiled on a different implementation (say, on DEC Alpha) which did it a
>> different way.
>
>
> For OS/360 Fortran IV, where ENTRY is listed as an extension.
> (grayed out in the manual), it seems to be partly by design.
>
> From GC28-6515-10, page 106.
>
> "Entry into a subprogram associates actual arguments with the
> dummy arguments referenced in the ENTRY statement. Thus, all
> appearances of these arguments in the whole subprogram become
> associated with the actual arguments. Arguments that were
> received by value at some previous use of the subprogram
> need not appear in the argument list of the ENTRY statement.
> Arguments that were received by location must appear. In this
> case, the reference will not transmit new values for the
> arguments not listed."
>
> OS/360 Fortran uses call by value result, also known as
> copy-in/copy-out, for scalar variables, and call by reference
> for arrays.
>
> As VAX Fortran inherited many extensions from OS/360 Fortran
> (to help porting programs) it is possible that it was
> intentional. As you know, it isn't required by the standard.

The way I remember VOS fortran working was that the arguments in the
entry statement had to match in type/size to those of the subroutine.
There could be fewer but not more arguments in an entry statement, but
they could be given different names in the entry statement and those
different names inherited the value of the arguments in the same
position as the argument in the subroutine statement if not called with
new values in the entry statement. Not sure if I have that right, but
that seemed to be the rules that I had to follow to get my terminal I/O
package to work correctly and consistently.

>
> -- glen
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Steve Lionel wrote:
(snip on ENTRY and the use of dummy variables)

> In some older implementations, it might seem to work "sort-of-magically", but
> not by design. VAX Fortran, for example, when you called the function would
> store in a fixed location the addresses of all the arguments and would just
> reference those locations no matter where you entered the procedure. I saw a
> lot of programs that depended on this "memory" behavior which then broke when
> compiled on a different implementation (say, on DEC Alpha) which did it a
> different way.

For OS/360 Fortran IV, where ENTRY is listed as an extension.
(grayed out in the manual), it seems to be partly by design.

From GC28-6515-10, page 106.

"Entry into a subprogram associates actual arguments with the
dummy arguments referenced in the ENTRY statement. Thus, all
appearances of these arguments in the whole subprogram become
associated with the actual arguments. Arguments that were
received by value at some previous use of the subprogram
need not appear in the argument list of the ENTRY statement.
Arguments that were received by location must appear. In this
case, the reference will not transmit new values for the
arguments not listed."

OS/360 Fortran uses call by value result, also known as
copy-in/copy-out, for scalar variables, and call by reference
for arrays.

As VAX Fortran inherited many extensions from OS/360 Fortran
(to help porting programs) it is possible that it was
intentional. As you know, it isn't required by the standard.

-- glen

Gordon Sande wrote:
> On 2008-09-03 01:38:41 -0300, Ron Ford <ron@example.invalid> said:
(snip regarding ENTRY and sin/cos calculation)

>> One is even; the other is odd. They might look pretty
>> much the same, but one is even; the other is odd.

> No! No! One is a delayed version of the other and both are twice delayed
> versions of themselves. In some fields it is called phase shifting. Others
> call it being periodic. It all depends on how you do the arguement
> reduction
> as both can be reduced to the same values over one quadrant. The heavy
> lifting (levelled approximation in numerical analysis) for that quadrant
> solves the whole problem.

Yes, but it should be done carefully.

The easy way is to define, such as with a statement function,

cos(x)=sin(x+1.57079632679)

besides the inexact value for pi/2, it makes argument
reduction even more inexact than it already is.

In the usual case of argument reduction, it is reduced
down to at least octants, and then the appropriate
expansion of a polynomial is used. That is, cos() of
values near pi/2 actually computes a sine series, and
sin near pi/2 uses a cosine series. Some might even
do argument reduction to smaller than an octant.

For functions like LOG and LOG10, the calculation
is the same up to a scale factor at the end.

-- glen

Richard Maine wrote:
(snip on ENTRY and sin/cos)

> You disagree that it was, in fact, done? Or even though it was done, you
> disagree that being even/odd wasn't a bar? I'm sorry, but in either case
> it simply isn't worth arguing about. In particular, it isn't worth my
> trouble to dig out citations. Most of the stuff I recall on this was
> well pre-net and thus might require non-trivial amounts of work to find.
> Glen might happen to have them around. He seems to have a lot of stuff
> from the era I'm thinking of, and he is obviously familliar with the
> methods that were used for this.

Yes, I have the source of the OS/360 sin/cos routine. I don't
think it is too useful to post it, but here are the
comments from the beginning describing the computation.

* SINE-COSINE FUNCTIONS (LONG)
* 1. DIVIDE MAGNITUDE OF ARG BY PI/4 TO FIND OCTANT
* AND FRACTION.
* 2. IF COSINE, ADD 2 TO OCTANT NUMBER.
* 3. IF SINE, ADD 0(4) TO OCTANT NUMBER FOR +ARG(-ARG).
* 4. COMPUTE SINE OR COSINE OF FRACTION*PI/4 DEPENDING
* ON THE OCTANT.
* 5. IF OCTANT NUMBER IS FOR LOWER PLANE, MAKE SIGN -.

and the ASIN/ACOS routine:

* ARCSIN-ARCCOSINE FUNCTION (LONG)
* 1. IF X BETWEEN 0 AND 1/2, COMPUTE ARCSIN BY POLYNOMIAL
* 2. IF X BETWEEN 1/2 AND 1,
* ARSIN(X) = PI/2-2*ARSIN(SQRT((1-X)/2))
* 3. IF X NEGATIVE, ARSIN(X) = -ARSIN(/X/)
* 4. ARCOS(X) = PI/2-ARSIN(X)

that one is even more interesting, as it uses self modifying
code to do the correction at the end depending on which entry
point was used.

One reason for using ENTRY is that it saves code
space in the days of small memory machines.

-- glen

On Sep 2, 11:45*pm, Ron Ford <r...@example.invalid> wrote:
> On Mon, 1 Sep 2008 21:02:59 -0700 (PDT), Will W. posted:
>
> > So what do I want to do?
> > ------------------------------------
> > Say I want to create a module of integration routines in xy Cartesian
> > geometry for integrating a user-specified function, f(x,y) over a
> > polygon. *Easy enough.
>
> I've never used fortran to integrate.
>
> What would f(x,y) look like in fortran, with, say, a parabola?
> --
> War will never cease until babies begin to come into the world with larger
> cerebrums and smaller adrenal glands. 2
> H. L. Mencken

You could do something like this.

FUNCTION Specific_Paraboloid(x,y) RESULT(f)
REAL,INTENT(IN) :: x,y
REAL :: f
!!--begin--A=1.0
B=2.0
C=3.0
D=4.0
E=5.0
F=6.0
f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
!!--end--
END FUNCTION

A more general possible usage could be this, where I have "imported"
the coefficients from a module called VAR_General_Paraboloid (VAR is
for variables), so that one could set the coefficients A-F before
doing the integration and get different paraboloids.

FUNCTION General_Paraboloid(x,y) RESULT(f)
USE VAR_General_Paraboloid,ONLY: A,B,C,D,E,F
REAL,INTENT(IN) :: x,y
REAL :: f
!!--begin--
f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
!!--end--
END FUNCTION

You can get even more general if you use a function parser, like
Stuart Midgley's, which lets you represent functions as text with
variables, then pass values of those variables to an evaluator, which
evaluates the function. This is very useful for reading functions
from input, for example, to read in general boundary conditions or
sources for a PDE solver. Then using the example of a 2D source,
which you would like to integrate over cells to get the cell-average
sources to stick in the RHS of a 2D finite volume method, the f(x,y)
might look like:

FUNCTION MySourceFunction(x,y) RESULT(f)
USE VAR_MySourceFunction,ONLY: FunctionID
REAL,INTENT(IN) :: x,y
REAL :: f
REAL :: error
!!--begin--

call s_evaluatefn(FunctionID, (/x,y/), f )

!!--end--
END FUNCTION

My source function is specified by the FunctionID handle, which is
returned when the function is created through the parser, with a call
like

call s_createfn( "1-tanh( (x-0.5)**2 + (y-0.4)**2 )" ,
"x y" , FunctionID )

Like I alluded to, I use the parser to read in boundary conditions as
functions, then use an integrator to evaluate the face-average values
on the boundary. Stuart Midgley's parser is quite nice. I highly
recommend it. It has quite a few functions, heaviside, hat, an if
statement if( logical-expression , true-val , false-val ), really more
of a substitution and the option to specify uncertainties with the
function's coefficients and propagate them
to output.
+W

On Sep 4, 1:47*pm, "Will W." <william.wieselqu...@gmail.com> wrote:
> On Sep 2, 11:45*pm, Ron Ford <r...@example.invalid> wrote:
>
> > On Mon, 1 Sep 2008 21:02:59 -0700 (PDT), Will W. posted:
>
> > > So what do I want to do?
> > > ------------------------------------
> > > Say I want to create a module of integration routines in xy Cartesian
> > > geometry for integrating a user-specified function, f(x,y) over a
> > > polygon. *Easy enough.
>
> > I've never used fortran to integrate.
>
> > What would f(x,y) look like in fortran, with, say, a parabola?
> > --
> > War will never cease until babies begin to come into the world with larger
> > cerebrums and smaller adrenal glands. 2
> > H. L. Mencken
>
> You could do something like this.
>
> FUNCTION Specific_Paraboloid(x,y) RESULT(f)
> REAL,INTENT(IN) :: x,y
> REAL :: f
> !!--begin--A=1.0
> B=2.0
> C=3.0
> D=4.0
> E=5.0
> F=6.0
> f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
> !!--end--
> END FUNCTION
>
> A more general possible usage could be this, where I have "imported"
> the coefficients from a module called VAR_General_Paraboloid (VAR is
> for variables), so that one could set the coefficients A-F before
> doing the integration and get different paraboloids.
>
> FUNCTION General_Paraboloid(x,y) RESULT(f)
> USE VAR_General_Paraboloid,ONLY: A,B,C,D,E,F
> REAL,INTENT(IN) :: x,y
> REAL :: f
> !!--begin--
> f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
> !!--end--
> END FUNCTION
>
> You can get even more general if you use a function parser, like
> Stuart Midgley's, which lets you represent functions as text with
> variables, then pass values of those variables to an evaluator, which
> evaluates the function. *This is very useful for reading functions
> from input, for example, to read in general boundary conditions or
> sources for a PDE solver. *Then using the example of a 2D source,
> which you would like to integrate over cells to get the cell-average
> sources to stick in the RHS of a 2D finite volume method, the f(x,y)
> might look like:
>
> FUNCTION MySourceFunction(x,y) RESULT(f)
> USE VAR_MySourceFunction,ONLY: FunctionID
> REAL,INTENT(IN) :: x,y
> REAL :: f
> REAL :: error
> !!--begin--
>
> call s_evaluatefn(FunctionID, (/x,y/), f )
>
> !!--end--
> END FUNCTION
>
> My source function is specified by the FunctionID handle, which is
> returned when the function is created through the parser, with a call
> like
>
> call s_createfn( "1-tanh( (x-0.5)**2 + (y-0.4)**2 )" ,
> * "x y" , FunctionID )
>
> Like I alluded to, I use the parser to read in boundary conditions as
> functions, then use an integrator to evaluate the face-average values
> on the boundary. *Stuart Midgley's parser is quite nice. *I highly
> recommend it. *It has quite a few functions, heaviside, hat, an if
> statement if( logical-expression , true-val , false-val ), really more
> of a substitution and the option to specify uncertainties with the
> function's coefficients and propagate them
> to output.
> +W

Naturally, the specific paraboloid should have declarations for A-F.

FUNCTION Specific_Paraboloid(x,y) RESULT(f)
REAL,INTENT(IN) :: x,y
REAL :: f
REAL :: A,B,C,D,E,F
!!--begin--
A=1.0
B=2.0
C=3.0
D=4.0
E=5.0
F=6.0
f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
!!--end--
END FUNCTION

On Sep 4, 3:35*pm, "Will W." <william.wieselqu...@gmail.com> wrote:
> On Sep 4, 1:47*pm, "Will W." <william.wieselqu...@gmail.com> wrote:
>
>
>
> > On Sep 2, 11:45*pm, Ron Ford <r...@example.invalid> wrote:
>
> > > On Mon, 1 Sep 2008 21:02:59 -0700 (PDT), Will W. posted:
>
> > > > So what do I want to do?
> > > > ------------------------------------
> > > > Say I want to create a module of integration routines in xy Cartesian
> > > > geometry for integrating a user-specified function, f(x,y) over a
> > > > polygon. *Easy enough.
>
> > > I've never used fortran to integrate.
>
> > > What would f(x,y) look like in fortran, with, say, a parabola?
> > > --
> > > War will never cease until babies begin to come into the world with larger
> > > cerebrums and smaller adrenal glands. 2
> > > H. L. Mencken
>
> > You could do something like this.
>
> > FUNCTION Specific_Paraboloid(x,y) RESULT(f)
> > REAL,INTENT(IN) :: x,y
> > REAL :: f
> > !!--begin--A=1.0
> > B=2.0
> > C=3.0
> > D=4.0
> > E=5.0
> > F=6.0
> > f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
> > !!--end--
> > END FUNCTION
>
> > A more general possible usage could be this, where I have "imported"
> > the coefficients from a module called VAR_General_Paraboloid (VAR is
> > for variables), so that one could set the coefficients A-F before
> > doing the integration and get different paraboloids.
>
> > FUNCTION General_Paraboloid(x,y) RESULT(f)
> > USE VAR_General_Paraboloid,ONLY: A,B,C,D,E,F
> > REAL,INTENT(IN) :: x,y
> > REAL :: f
> > !!--begin--
> > f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
> > !!--end--
> > END FUNCTION
>
> > You can get even more general if you use a function parser, like
> > Stuart Midgley's, which lets you represent functions as text with
> > variables, then pass values of those variables to an evaluator, which
> > evaluates the function. *This is very useful for reading functions
> > from input, for example, to read in general boundary conditions or
> > sources for a PDE solver. *Then using the example of a 2D source,
> > which you would like to integrate over cells to get the cell-average
> > sources to stick in the RHS of a 2D finite volume method, the f(x,y)
> > might look like:
>
> > FUNCTION MySourceFunction(x,y) RESULT(f)
> > USE VAR_MySourceFunction,ONLY: FunctionID
> > REAL,INTENT(IN) :: x,y
> > REAL :: f
> > REAL :: error
> > !!--begin--
>
> > call s_evaluatefn(FunctionID, (/x,y/), f )
>
> > !!--end--
> > END FUNCTION
>
> > My source function is specified by the FunctionID handle, which is
> > returned when the function is created through the parser, with a call
> > like
>
> > call s_createfn( "1-tanh( (x-0.5)**2 + (y-0.4)**2 )" ,
> > * "x y" , FunctionID )
>
> > Like I alluded to, I use the parser to read in boundary conditions as
> > functions, then use an integrator to evaluate the face-average values
> > on the boundary. *Stuart Midgley's parser is quite nice. *I highly
> > recommend it. *It has quite a few functions, heaviside, hat, an if
> > statement if( logical-expression , true-val , false-val ), really more
> > of a substitution and the option to specify uncertainties with the
> > function's coefficients and propagate them
> > to output.
> > +W
>
> Naturally, the specific paraboloid should have declarations for A-F.
>
> FUNCTION Specific_Paraboloid(x,y) RESULT(f)
> REAL,INTENT(IN) :: x,y
> REAL :: f
> REAL :: A,B,C,D,E,F
> !!--begin--
> A=1.0
> B=2.0
> C=3.0
> D=4.0
> E=5.0
> F=6.0
> f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F
> !!--end--
> END FUNCTION

and your return value was f, so you can't use F for a coefficient---
use G instead (working in C++ lately).

FUNCTION Specific_Paraboloid(x,y) RESULT(f)
REAL,INTENT(IN) :: x,y
REAL :: f
REAL :: A,B,C,D,E,G
!!--begin--
A=1.0
B=2.0
C=3.0
D=4.0
E=5.0
G=6.0
f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + G
!!--end--
END FUNCTION

Will W. wrote:
(snip)

> f = A*x**2 + B*x + C*x*y + D*y**2 + E*y + F

Last I knew, it was A*x**2 + B*x*y + C*y**2 + D*x + E*y + F

That makes the discriminant B**2-4*A*C, (sound familiar?),
which is positive for ellipse, zero for parabola, and
negative for hyperbola.

-- glen

On 2 sep, 06:02, "Will W." <william.wieselqu...@gmail.com> wrote:
> Main question
> ---------------------
> Can anyone think of a way to provide such a collection of wrappers
> like the example Integrate_ABC above for integABC?
>

You could consider inverse communication, as sketched below:

User code:

call integrate( ... , mode=initialise )

do while ( cont )
call integrate( ..., xvalue, fvalue, result, cont, mode )

if ( mode = compute ) then
fvalue = f( xvalue, ... )
endif
enddo

write(*,*) 'Result: ', result

That way you can use just about any interface to the actual
function and still have general code.

The details can get a bit tricky, though .

Regards,

Arjen