(j3.2006) J3/09-292 - J3 Fortran interp letter ballot #19 - due19-Oct-2009

[Bill Long]

Ballot #19 from Bill Long, Cray Inc.


The following Fortran interpretations are being balloted:


Yes  No   Number     Title



-Y-  ---  F95/0098   Are dummy functions returning assumed-length

                             character legal?

-Y-  ---  F03/0022   Coexistence of IEEE and non-IEEE kinds

-Y-  ---  F03/0024   DEALLOCATE and array pointers

-Y-  ---  F03/0034   IEEE_LOGB()

---  -N-  F03/0039   HYPOT()

-Y-  ---  F03/0078   IEEE_SUPPORT_DATATYPE vs. mathematical equivalence

-C-  ---  F03/0090   Polymorphic array constructors

-Y-  ---  F03/0130   Elemental specific intrinsic procedure

                             characteristics

-Y-  ---  F03/0131   SAVE attribute and EQUIVALENCE

-Y-  ---  F03/0132   Unformatted i/o and private components

-C-  ---  F03/0133   Is unlimited polymorphic allowed in COMMON?

-Y-  ---  F03/0134   Implicit typing of procedure pointers

-Y-  ---  F03/0135   Interaction between RESULT, recursion, and host

                             generic

-C-  ---  F03/0136   Are subroutines distinguishable from arrays?

-Y-  ---  F03/0137   Dummy procedure type compatibility

-Y-  ---  F03/0138   External <procedure-name> as <proc-target>


-----------------------------------
Comments:


F03/0039:
---------

The text in the IEEE 754-2008 standard says (bottom of page 43):

"For the hypot function, hypot(?0, ?0) is +0, hypot(??, qNaN) is +?,
and hypot(qNaN, ??) is +?. "

If the argument for changing the rules for IEEE_LOGB() in Interp
F03/0034 is to make the Fortran rules match the IEEE rules, then the
same argument would seem to apply here.  Yet the changes I see
proposed do not result in HYPOT returning the IEEE-required results
when one of the arguments is a NaN and the other is an Infinity.

If we really want the results to be NaN, then the interp should
clearly state that the values we require contradict the IEEE rules.


F03/0090:
---------

As noted by John and others, the functions in both examples should be
named f, or the references to f within functions f1 and f2 should be
changed to f1 and f2 respectively.


F03/0133:
---------

It appears that this interp effectively replaces F03/0046. For future
tracking, it might be valuable to include cross references in both
interps.

Jim suggested that declaration of an unlimited polymorphic pointer
should be disallowed in BLOCK DATA program units. Since the 'harm'
occurs only if the object so declared also appears in a COMMON block,
I don't see the need for this extra prohibition.


F03/0136:
---------

I agree with Jim that the definition of aprintf should start

    subroutine aprintf(af,n)

so that n has a chance of being defined before its use in the Print
statement. Furthermore without the n, the routines are distinguishable
based on argument count, circumventing the intent of the example.

I also think that the second example would be improved by adding the
first 5 lines and the last line from the first example.  Taken
literally there is no problem with the second example - the issue
comes in the context of the generic resolution, and there is no
generic interface in the current second example.



-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120