Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A NOTE AND A DIALOG ON ASPECTS* OF THE DOD COMMON LANGUAGE (IRONMAN)

IP.com Disclosure Number: IPCOM000128232D
Original Publication Date: 1978-Dec-31
Included in the Prior Art Database: 2005-Sep-15
Document File: 4 page(s) / 19K

Publishing Venue

Software Patent Institute

Related People

ROBERT B. K. DEWAR: AUTHOR [+3]

Abstract

This report contains a note written following a discussicn of the real p:_ecisxon problem in Ironman at the Twente, Hollard meeting of WG2.4earlier this year. It also contairis a verbatim, un unexpurgated version of a written dialog on exception handling in green which o~-.cured at this conference during one of the sessions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 1 of 4

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

A NOTE AND A DIALOG ON ASPECTS* OF THE DOD COMMON LANGUAGE (IRONMAN)

BY ROBERT B. K. DEWAR

October 1978 Report No. 005 This report contains a note written following a discussicn of the real p:_ecisxon problem in Ironman at the Twente, Hollard meeting of WG2.4earlier this year. It also contairis a verbatim, un unexpurgated version of a written dialog on exception handling in green which o~-.cured at this conference during one of the sessions. *"This work was supported in part by NSF Grant Tao. MCS76-00115 , from The National Sciences Foundation. Any opinions, findings, and conclusions or recommendations expressed in this publication are these of the author (s) and do not necessarily reflect the views of The National Science Foundation."

2 PART I IRON MAN REALS AND THE INFAMOUS "SQU.URE ROOT" PROBLEM

R. DEWAR If several variables are declared: REAL (8 ) REAL (12 ) REAL (15 ) Then the question arises of how many types are present; there are three possible answers: (1) 3 - Each separate precision is a separate type, regardless of implementation. (ii) 1 - All precisions are one type (the precision is an attribute) (Ironman) . (iii) 2 (or maybe 1 or 3!) - my machine was single precision up to 9, double precision up to 18. We can also ask how many square root routines are required (by overloading) and get three answers. This question makes it immediately clear that answer (iii)(depends on machine) is untenable since it means that the number of square root routines depends on the hardware, which, from a portability point of view at least, is absurd. ( footnote at end). If we take approach (i) then we surely discourage the accurate specification of precision because we will need to write many square root routines with identical bodies (this we know is a naive view, since the algorithm may depend on the precision, but let it pass for now - if it really bothers, replace sqrt by square in the preceeding discussion). 3

Thus we see how Ironman arrived at answer (ii). We also have the analog in ALGOL-60 and ALGOL-68 arrays where all arrays a (of the same number of dimensions) are one type and one need not write a separate sum procedure for each array length. What about implementation of
(ii)? Well let us follow the array analog further:

(Equation Omitted)

efficient code, no less efficient code, dope vector, no check dope vector required

Now applying the same principle to real precisions we have:

(Equation Omitted)

efficient code, no less efficient code, dope vector, no check dope vector required The "dope vector" for a real is simply an extra tag containing its precision. Normally they ca.^.^. be omitted but not in the awkward cases. The type system is intact, but the thought of the dynamic checks Involved is somewhat unpleasant. It is possible to use the usual incantation: "Oh optimizer, examine the program, yea even unto the inter-procedural level, and divine, if possible, all tho...