generic interface real function vs real
in [Fortran]
|
Prev: Can someone know the time for a oo implemented F2003 complier release under the window platform?
Next: Derived type argument to subroutine
From: Herman D. Knoble on 17 Apr 2008 08:37 Have you tried overloading (on arg type) ? Skip Knoble On Wed, 16 Apr 2008 15:13:54 -0700 (PDT), mabrowning <mabrowningrr(a)gmail.com> wrote: -|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
From: Gerry Ford on 18 Apr 2008 00:43 "FX" <coudert(a)alussinan.org> wrote in message news:fu5up8$15hd$1(a)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
From: FX on 18 Apr 2008 04:00 [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
From: Craig Dedo on 18 Apr 2008 08:07 "Steve Lionel" <steve.lionel(a)intel.invalid> wrote in message news:YaxNj.16048$vz2.11366(a)trndny05... > Richard Maine wrote: >> FX <coudert(a)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: <cdedo(a)wi.rr.com> or <craig(a)ctdedo.com>
From: Craig Dedo on 18 Apr 2008 08:31
"Craig Dedo" <cdedo(a)wi.rr.com> wrote in message news:48088ef1$0$5719$4c368faf(a)roadrunner.com... > "Steve Lionel" <steve.lionel(a)intel.invalid> wrote in message > news:YaxNj.16048$vz2.11366(a)trndny05... >> Richard Maine wrote: >>> FX <coudert(a)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? > 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] -- 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: <cdedo(a)wi.rr.com> or <craig(a)ctdedo.com> |