generic interface real function vs real

mabrowning

unread,

Apr 16, 2008, 6:13:54 PM4/16/08

to

I am trying to create a subroutine that can either take a time
dependent function, or a constant.

It compiles and runs perfectly with GNU Fortran (GCC) 4.2.3, but ifort
(IFORT) 10.0 20070426 complains:

fortcom: Warning: generic.f90, line 13: The type/rank/keyword
signature for this specific procedure matches another specific
procedure that shares the same generic-name. [FOO_SCALAR]
SUBROUTINE foo_scalar(A)
-------------------^

It looks like the function signature and the scalar signature are the
same? This doesn't seem to make sense!

---------------------------------------------------------------------------
example:

MODULE foo
INTERFACE generic
MODULE PROCEDURE foo_fun, foo_scalar
END INTERFACE
CONTAINS
SUBROUTINE foo_fun(f)
INTERFACE
REAL FUNCTION f(t)
REAL t
END FUNCTION
END INTERFACE
WRITE(*,*)f(1.0)
END SUBROUTINE
SUBROUTINE foo_scalar(A)
REAL A
WRITE(*,*)A
END SUBROUTINE
END MODULE

PROGRAM main
USE foo
REAL ::A=1.0
REAL, EXTERNAL :: f
CALL generic(A)
CALL generic(f)
END PROGRAM

REAL FUNCTION f(t)
REAL t
f=t
END FUNCTION

james...@att.net

unread,

Apr 16, 2008, 6:30:10 PM4/16/08

to

On Apr 16, 4:13 pm, mabrowning <mabrownin...@gmail.com> wrote:
> I am trying to create a subroutine that can either take a time
> dependent function, or a constant.

...

Unfortunately, the resolution of which specific to call is
based entirely and only on four criteria: 1) number of arguments,
and for each of those arguments 2) type, 3) KIND, and 4) rank.
In your example, both your functions accept only one argument,
and that argument is REAL, default KIND, and rank zero (scalar).
So, for the purposes of Fortran procedure overloading, those
functions are not usefully different.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

FX

unread,

Apr 16, 2008, 6:32:08 PM4/16/08

to

> It compiles and runs perfectly with GNU Fortran (GCC) 4.2.3, but ifort
> (IFORT) 10.0 20070426 complains

I was going to say that this is an Intel bug, because it looked OK to me
and other compilers certainly did accept it (Sun, gfortran, IBM) but
Lahey also complains. So, I looked into the F2003 standard and I think
that's what the last example (INTERFACE BAD9) of C.11.2 says: it is
unambiguous, but still invalid, because: "the rules do not distinguish on
the basis of any properties other than type, kind type parameters, and
rank".

Anyone willing to confirm/infirm this?

PS: the root cause for that might be the will to have some simpler rules,
but it is a bit sad if the example showed by the poster is invalid
(moreover, these rules *are* complex anyway).

--
FX

Richard Maine

unread,

Apr 16, 2008, 6:59:46 PM4/16/08

to

FX <cou...@alussinan.org> wrote:

> "the rules do not distinguish on
> the basis of any properties other than type, kind type parameters, and
> rank".
>
> Anyone willing to confirm/infirm this?

That's correct. Thus the common abbreviation TKR (for type,kind, and
rank). That combination comes up enough to merit an abbreviation.

> PS: the root cause for that might be the will to have some simpler rules,
> but it is a bit sad if the example showed by the poster is invalid
> (moreover, these rules *are* complex anyway).

Indeed the rules are complex in that area. And there must be about a
dozen different proposals for enhancing the rules, including some
proposals that are directly incompatible with each other. That is
definitely an area where "this enhancement would be nifty" is nowhere
near a good enough selling point. It takes a lot of looking at the
cost/benefit, including the impact on other potential enhancements.

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

Steve Lionel

unread,

Apr 16, 2008, 8:52:08 PM4/16/08

to

Richard Maine wrote:
> FX <cou...@alussinan.org> wrote:
>
>> "the rules do not distinguish on
>> the basis of any properties other than type, kind type parameters, and
>> rank".
>>
>> Anyone willing to confirm/infirm this?
>
> That's correct. Thus the common abbreviation TKR (for type,kind, and
> rank). That combination comes up enough to merit an abbreviation.

Right. I recall this issue very well and wrote up the problem report,
since earlier versions of ifort did allow this. The key, as Richard
says, is that "procedureness" (my word) is not a distinguishing factor
for generic resolution.
--
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/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

Herman D. Knoble

unread,

Apr 17, 2008, 8:37:20 AM4/17/08

to

Have you tried overloading (on arg type) ?

Skip Knoble

On Wed, 16 Apr 2008 15:13:54 -0700 (PDT), mabrowning <mabrow...@gmail.com> wrote:

Gerry Ford

unread,

Apr 18, 2008, 12:43:18 AM4/18/08

to

"FX" <cou...@alussinan.org> wrote in message
news:fu5up8$15hd$1...@nef.ens.fr...

>> It compiles and runs perfectly with GNU Fortran (GCC) 4.2.3, but ifort
>> (IFORT) 10.0 20070426 complains
>
> I was going to say that this is an Intel bug, because it looked OK to me
> and other compilers certainly did accept it (Sun, gfortran, IBM) but
> Lahey also complains. So, I looked into the F2003 standard and I think
> that's what the last example (INTERFACE BAD9) of C.11.2 says: it is
> unambiguous, but still invalid, because: "the rules do not distinguish on
> the basis of any properties other than type, kind type parameters, and
> rank".

I think that TKR is the expression I've been reaching for when I wondered
what "type" the implementation gives. This from g95 had kind where it
should have type:

KIND types available in the g95 compiler (at the time of writing quad
precisison is not yet available).

+------------------+----------+------------------+--------------------------+--------------------------+ | Kind | Memory | Precision | Smallest value, TINY()| Largest value, HUGE() | +------------------+----------+------------------+--------------------------+--------------------------+ | REAL (KIND=4 )* | 4 bytes | 7 s.f. (Single) | 1.1754944E-38| 3.4028235E+38 | | REAL (KIND=8 ) | 8 bytes | 15 s.f. (Double) | 2.2250738585072014E-308| 1.7976931348623157E+308 | | REAL (KIND=16) | 16 bytes | 34 s.f. (Quad) || | +------------------+----------+------------------+--------------------------+--------------------------+ +------------------+----------+----------------------------+ | Kind | Memory | Range | +------------------+----------+----------------------------+ | INTEGER (KIND=1) | 1 byte | -128 to 127 | | INTEGER (KIND=2) | 2 bytes | -32768 to 32767 | | INTEGER (KIND=4)*| 4 bytes | -2147483648 to 2147483647 | * meansdefault kind. | INTEGER (KIND=8) | 8 bytes | about +- 9.2x10^18 | s.f. means"significant figures". +------------------+----------+----------------------------+>> Anyone willing to confirm/infirm this?You crack me up, FX. I'm certain that there's a logical motivation for whatthe negation of con- is. You'll find that "infirm" in common parlance is anadjective in anglaise. I'd have to think a bit what the proper antonymwould be.To distract myself as I fall asleep lately, I've been watching my dvd's inforeign languages. "Black Hawk Down" was surprisingly authentic in french.Machine guns all speak the same language.Funnier was "young frankenstein" in spanish: Yo soy Frau Bluecher.--"A belief in a supernatural source of evil is not necessary; men aloneare quite capable of every wickedness."~~ Joseph Conrad (1857-1924), novelist

FX

unread,

Apr 18, 2008, 4:00:28 AM4/18/08

to

[AS: Gerry, you might want to check on your newsreader settings; yours
posts often appear to me lacking newline characters, which makes them
quite hard to read. Also, it's easier if you use quoting the same as
others here, by prefixing each line you quote with a ">".]

>> Anyone willing to confirm/infirm this?
>

> You'll find that "infirm" in common parlance is an adjective

Indeed; I apologise. I was mislead by french where "infirm", in addition
to meaning ailing or disable, is also a verb that means something like
"contradict with a greater authority" (an appeal court would use it to
overrule the judgment of a lower court).

--
FX

Craig Dedo

unread,

Apr 18, 2008, 8:07:14 AM4/18/08

to

"Steve Lionel" <steve....@intel.invalid> wrote in message
news:YaxNj.16048$vz2.11366@trndny05...

> Richard Maine wrote:
>> FX <cou...@alussinan.org> wrote:
>>
>>> "the rules do not distinguish on
>>> the basis of any properties other than type, kind type parameters, and
>>> rank".
>>>
>>> Anyone willing to confirm/infirm this?
>>
>> That's correct. Thus the common abbreviation TKR (for type,kind, and
>> rank). That combination comes up enough to merit an abbreviation.
>
> Right. I recall this issue very well and wrote up the problem report, since
> earlier versions of ifort did allow this. The key, as Richard says, is that
> "procedureness" (my word) is not a distinguishing factor for generic
> resolution.
> --
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH

Two points:

1. The term "procedureness" has been in use at least within J3 for over 10
years. From my time on J3, I distinctly remember it being used frequently,
especially when considering interpretations.

2. This rule may change in Fortran 2008. Using procedureness in generic
resolution is work item UK-009, proposed by Malcolm Cohen. The relevant paper
is J3/05-245r1. Does any current J3 member know if this feature has made it
into the curent Fortran 2008 draft?

--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>

Craig Dedo

unread,

Apr 18, 2008, 8:31:28 AM4/18/08

to

"Craig Dedo" <cd...@wi.rr.com> wrote in message
news:48088ef1$0$5719$4c36...@roadrunner.com...

I answered my own question. Yes, using procedureness in generic resolution
is in Fortran 2008. Here is the relevant text from the current draft, 08-007r2.
Reference is sec. 12.4.3.4.5, par. 3.
[Begin quote]
Two dummy arguments are distinguishable if:
* One is a procedure and the other is a data object,
[End of quote]

Dan Nagle

unread,

Apr 18, 2008, 9:35:19 AM4/18/08

to

Hello,

On 2008-04-18 08:31:28 -0400, "Craig Dedo" <cd...@wi.rr.com> said:
> Here is the relevant text from the current draft, 08-007r2. Reference
> is sec. 12.4.3.4.5, par. 3.
> [Begin quote]
> Two dummy arguments are distinguishable if:
> * One is a procedure and the other is a data object,
> [End of quote]

Prehaps easier than thumbing through the standard
would be to go to J3's home page, click on "work plan",
and note that UK-009 has an "Edits" paper passed.

There is even a link to the edits paper.

--
Cheers!

Dan Nagle

Craig Dedo

unread,

Apr 18, 2008, 12:23:00 PM4/18/08

to

"Dan Nagle" <dann...@verizon.net> wrote in message
news:2008041809352075249-dannagle@verizonnet...

Thant's how I found it in the first place. However, just because an edits
paper passed does not mean that the feature made it all the way into the current
draft. It could have slipped between the cracks or gotten pulled at a later
date. Features have been fully developed only to be pulled later. Remember
Named Scratch Files? More recently, the BITS feature.

So, I decided to check the current draft to make sure that the feature is
still there.

Gerry Ford

unread,

Apr 19, 2008, 6:27:51 PM4/19/08

to

"FX" <cou...@alussinan.org> wrote in message

news:fu9kes$2fgf$1...@nef.ens.fr...

Nonsense, it is I who apologizes. I made a completely garbled point that
you could read as a criticism. The part about misidentification of kind in
g95 is here: http://zaxfuuq.net/fortran196915.jpg .

Those of us who speak English natively appreciate those who communicate in a
foreign language. It would be a lot tougher for me in French. Jens se non
declaration pas ....

As to the antonym for confirm in english, I think you'd have to go with deny
or disprove. I'm certain that infirm in french works better.
--

John Harper

unread,

Apr 20, 2008, 6:18:29 PM4/20/08

to

In article <1208643...@news.newsgroups.com>,

Gerry Ford <ge...@nowhere.ford> wrote:
>
>As to the antonym for confirm in english, I think you'd have to go with deny
>or disprove. I'm certain that infirm in french works better.

As well as deny and disprove, English offers rebut, confute and refute.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045