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

On Tue, 2 Sep 2008 10:26:57 -0600, "James Van Buskirk" <not_valid@comcast.net>
wrote:

>> > >Is there any possibility the ability to pass an internal function as
>> > >an argument is going to be added to the standard?
>
>> > This is in the current draft for Fortran 2008. Some compilers (e.g.
>> > Intel
>> > Fortran) already support this.
>
>> GREAT. Do you happen to know as of which version it is supported for
>> Intel? We have 9.1 on our linux cluster and I would like to be able
>> to use it there. Thanks,
>
>Since approximately DVF.

Yup. 8.0 and later on the Intel side,. I know that DVF/CVF had it for
several years - probably since DVF 6.0, but I don't remember exactly when it
was added.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/per...etools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

Richard Maine wrote:

> Entry has a large number of "quirks" and special cases. At one time it
> was on a list of features to be declared obsolescent. I don't recall
> whether that survived the development process to date, but in any case,
> I would not personally recommend using ENTRY for anything in new code. A
> module provides a better way of doing most of this style of thing (where
> two procedures share some of the same data).

The other case is where they share most of the same code,
an example being SIN and COS. (Not that you would write
them in Fortran, but if you did...)

It seems that some compilers implement anything with ENTRY
as wrapper routines that accept the appropriate arguments, and
then call another that does all the work. (This is visible
in gdb if you put a breakpoint on the entry point.)
You could do the same thing directly in Fortran code.

-- glen

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

On Tue, 02 Sep 2008 10:02:39 -0800, glen herrmannsfeldt posted:

> Richard Maine wrote:
>
>> Entry has a large number of "quirks" and special cases. At one time it
>> was on a list of features to be declared obsolescent. I don't recall
>> whether that survived the development process to date, but in any case,
>> I would not personally recommend using ENTRY for anything in new code. A
>> module provides a better way of doing most of this style of thing (where
>> two procedures share some of the same data).
>
> The other case is where they share most of the same code,
> an example being SIN and COS. (Not that you would write
> them in Fortran, but if you did...)

One is even; the other is odd. They might look prettymuch the same, but
one is even; the other is odd.

>
> It seems that some compilers implement anything with ENTRY
> as wrapper routines that accept the appropriate arguments, and
> then call another that does all the work. (This is visible
> in gdb if you put a breakpoint on the entry point.)
> You could do the same thing directly in Fortran code.

I've never used entry in my own code. It sounds like its usage is like a
cast from C. I would very much question its use from the gitgo as opposed
to patching something that needed to be fixed.

Maybe, it depreciated.
--
War will never cease until babies begin to come into the world with larger
cerebrums and smaller adrenal glands. 2
H. L. Mencken

On 2 sep, 16:27, Steve Lionel <Steve.Lio...@intel.invalid> wrote:
> On Tue, 2 Sep 2008 04:53:56 -0700 (PDT), Arjen Markus
>
>
>
>
>
> <arjen.mar...@wldelft.nl> wrote:
> >real function integrate_abc( f, n, pg, reltol )
> > * *... appropriate declarations
>
> > * *... preparation
> > * *call integabc( flocal, ... )
> > * *... completion
> > * *return
>
> >!
> >! Here it comes
> >!
> >entry flocal( pg )
>
> > * flocal = f(pg)
>
> >end function
>
> This is illegal - when entered through flocal, dummy argument f is not allowed
> to be referenced since it is not in the dummy argument list of flocal.
> --
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
> For email address, replace "invalid" with "com"
>
> User communities for Intel Software Development Products
> *http://softwareforums.intel.com/
> Intel Fortran Support
> *http://support.intel.com/support/per...etools/fortran
> My Fortran blog
> *http://www.intel.com/software/drfortran- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Ah, I had hoped it would sort-of-magically be available.

I have seen ENTRY used in one or two programs, I may have
used in one of my own programs a long time ago.

So I completely misjudged it .

Regards,

Arjen

Ron Ford <ron@example.invalid> wrote:

> On Tue, 02 Sep 2008 10:02:39 -0800, glen herrmannsfeldt posted:
[about uses of entry]
> > The other case is where they share most of the same code,
> > an example being SIN and COS. (Not that you would write
> > them in Fortran, but if you did...)
>
> One is even; the other is odd. They might look prettymuch the same, but
> one is even; the other is odd.

That's completely irrelevant. They can in fact be computed with largely
the same code, as Glen noted. Indeed, it used to be common practice to
do so. Because of the commonality, some library routines even returned
both in a single call. Being even/odd isn't a bar at all.

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

On Wed, 3 Sep 2008 00:50:58 -0700, Richard Maine posted:

> Ron Ford <ron@example.invalid> wrote:
>
>> On Tue, 02 Sep 2008 10:02:39 -0800, glen herrmannsfeldt posted:
> [about uses of entry]
>>> The other case is where they share most of the same code,
>>> an example being SIN and COS. (Not that you would write
>>> them in Fortran, but if you did...)
>>
>> One is even; the other is odd. They might look prettymuch the same, but
>> one is even; the other is odd.
>
> That's completely irrelevant. They can in fact be computed with largely
> the same code, as Glen noted. Indeed, it used to be common practice to
> do so. Because of the commonality, some library routines even returned
> both in a single call. Being even/odd isn't a bar at all.

I disagree. Is it possible that either call could err, even by an
uninformed caller?? I'm certain that you and everyone remembers proper
phase shifts, shit I forgot before college.

Given error, I'd look at the infinite sum as terms differs. Does it go
like (x + .01)**0 + (x + .01)**2/2!+sigma_over evens or (x + .01)**1+ (x
+ .01)**3/3! +sigma over odds.

Dick Cheney, war criminal, arrives in Azerbaijan. You talk to him, you
don't talk to us.
--
War will never cease until babies begin to come into the world with larger
cerebrums and smaller adrenal glands. 2
H. L. Mencken

On 2008-09-03 01:38:41 -0300, Ron Ford <ron@example.invalid> said:

> On Tue, 02 Sep 2008 10:02:39 -0800, glen herrmannsfeldt posted:
>
>> Richard Maine wrote:
>>
>>> Entry has a large number of "quirks" and special cases. At one time it
>>> was on a list of features to be declared obsolescent. I don't recall
>>> whether that survived the development process to date, but in any case,
>>> I would not personally recommend using ENTRY for anything in new code. A
>>> module provides a better way of doing most of this style of thing (where
>>> two procedures share some of the same data).
>>
>> The other case is where they share most of the same code,
>> an example being SIN and COS. (Not that you would write
>> them in Fortran, but if you did...)
>
> One is even; the other is odd. They might look prettymuch 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.

On Tue, 2 Sep 2008 23:45:37 -0700 (PDT), Arjen Markus
<arjen.markus@wldelft.nl> wrote:


>> This is illegal - when entered through flocal, dummy argument f is not allowed
>> to be referenced since it is not in the dummy argument list of flocal.
>
>Ah, I had hoped it would sort-of-magically be available.
>
>I have seen ENTRY used in one or two programs, I may have
>used in one of my own programs a long time ago.
>
>So I completely misjudged it .

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.

So I have no doubt that you saw programs that tried to take advantage of such
behavior in the past. They would be unlikely to run with any modern Fortran
compiler.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/per...etools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

Ron Ford <ron@example.invalid> wrote:

> On Wed, 3 Sep 2008 00:50:58 -0700, Richard Maine posted:
>
> > Ron Ford <ron@example.invalid> wrote:
> >
> >> On Tue, 02 Sep 2008 10:02:39 -0800, glen herrmannsfeldt posted:
> > [about uses of entry]
> >>> The other case is where they share most of the same code,
> >>> an example being SIN and COS. (Not that you would write
> >>> them in Fortran, but if you did...)
> >>
> >> One is even; the other is odd. They might look prettymuch the same, but
> >> one is even; the other is odd.
> >
> > That's completely irrelevant. They can in fact be computed with largely
> > the same code, as Glen noted. Indeed, it used to be common practice to
> > do so. Because of the commonality, some library routines even returned
> > both in a single call. Being even/odd isn't a bar at all.
>
> I disagree. Is it possible that either call could err, even by an
> uninformed caller??

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.

If you choose to think that you know enough about basic algorithms to
dispute the question, so be it. I'm not on this group to teach basic
algorithms or to argue with those in need of such material. As Glen
noted, this isn't particularly a Fortran matter. This isn't even the
"interesting" part of algorithms for computing sin and cos; that would
probably be the issue of large argument values, as discussed here on
occasion. Though both relate to argument reduction (see Gordon's post).

No, the usual algorithms aren't subject to error particularly more than
any others.

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