Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!sri-unix!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: Fortran vs C for computations Message-ID: <379@quintus.UUCP> Date: 12 Sep 88 00:52:02 GMT References: <373@quintus.UUCP> <3385@lanl.gov> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 149 In article <3385@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <373@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe): >> >> We could have something like >> CALL HANDLE(exception, handler, oldhandler, ierror) >> where ierror would be set to a suitable value if the implementation was >> not able to catch that kind of error. For example, >> CALL HANDLE('OVERFLOW', MYOVHD, OLDHD, IERROR) >> IF (IERROR .NE. 0) STOP 'CAN''T CATCH OVERFLOWS' > >How does this suggestion differ from the supplimentary standard idea I >proposed in my last article (which you criticized the first part and appear >to have ignored the rest)? Life is too short to criticise everything that warrants criticism. Perhaps I misunderstood what a "supplementary standard" is supposed to be. What I was suggesting is that there should be a _standard_ way of catching exceptions which is required of *EVERY* implementation, but that this standard method is allowed to return a standard "Sorry boss, no can do" result. With such an interface, you write *one* version of the program which selects between two cases: detection and handling are possible or they are not. I used 'STOP' in my example to keep it short; another reasonable alternative would be to print a message warning that the results might be complete and utter rubbish, and proceed with the calculation. I understood a "supplementary standard" to be something like a "module" in standard COBOL, where a feature may be completely missing. That simply isn't good enough. If the feature is in a "supplementary standard", so that it may or may not be present in an implementation, then you have to prepare two versions of the source code of your program. (At *least* two.) That's precisely the kind of problem which standards are supposed to prevent. In my proposal, the feature must *always* be present, so only one version of the source code is needed. >My point is that it shouldn't be part of the >language definition for two reasons: 1) it means that any machine/system >that can't support it won't be able to have a standard conforming environ- >ment; Apart from questions of storage, there can be no such machine. It might be _expensive_ to support exception handling, but that's not the same thing as impossible. Computers exist to execute programs, NOT the other way around. Are we to require that no Fortran program may use more than 640k of data? Some machines/systems can't support more than that! >2) if it's part of the language definition, different languages >will undoubtedly define the mechanism in different - mutually incompatible >ways. But "benign neglect" such as you propose is precisely what has got us into this mess! PL/I, COBOL, and ADA *already* provide standardised ways of handling (and optionally suppressing) arithmetic exceptions. The only difference that leaving exception handling out of FORTRAN makes is that it makes FORTRAN incompatible with itself. >Indeed, something like what you suggest _is_ available on all the >large-scale Fortran environments I've ever worked on. This claim greatly reduces the force of Giles' argument against it! >The problem isn't >that Fortran doesn't have it and C does (C doesn't - the C library sometimes >does - the ANSI C standard _may_ require it), the problem is that there >is no language-independent standard for this functionality. (a) The distinction between C-the-language and C-the-library is bogus. Is matherr missing from some implementations of C? So is floating- point arithmetic. Is floating-point arithmetic in the draft ANSI standard? So is signal(). (b) There is no language-independent standard for input/output. Does that mean that input/output should not be part of a FORTRAN standard? Until IEEE 754, there was no language-independent standard for floating-point arithmetic (and machines designed before that standard do not follow it). Does that mean that floating-point arithmetic should not be in a FORTRAN standard? There is no language-independent standard for integer arithmetic! (Integers are obviously 36-bit 2s-complement, right? Or is it 32? Or 16? No, they're obviously sign + 39-bit magnitude...) PL/I FIXED data don't follow exactly the same rules as COBOL NUMERIC, and FORTRAN is different from both. By Giles' rule, INTEGER arithmetic should be omitted from the FORTRAN standard, perhaps left to a "supplementary standard". There is no language-indpendent standard for alternate returns, yet they are part of the 1978 FORTRAN standard. >> Good heavens, if we were to accept the "some machines don't want to do it" >> argument, we wouldn't have floating-point arithmetic, and then where would >> Fortran be? > >Some machines _don't_ have floating-point! I know that. I'm using one. >(I've >talked with hardware designers and it's not as easy as you seem to >think. Consider overflow for example. You want to intercept the >exception and do something to fix-up the result. You are putting words in my mouth. I DO NOT BELIEVE IN "FIXING-UP". All I want to know is whether an exception occurred. I'm not asking for the incredibly hairy PL/I exception handling system with its ON* pseudo-variables. An ADA-style scheme where exceptions cause the block then executing to be exited and the only information provided is that such-and-such an exception occurred within the scope of such-and-such a handler would be enough to ensure that garbage results did not go undetected. >On a vector machine, >how do you tell which vector element needs fixing? I don't particularly want to know. If for some reason I want to know, a scheme like this: ON (OVERFLOW) IN DO 10 I = 1, N A(I) = B(I)+C(I) 10 CONTINUE HANDLER DO 20 I = 1, N ON (OVERFLOW) IN A(I) = B(I)+C(I) HANDLER PRINT *, 'OVERFLOW AFFECTED A(',I,')' A(I) = 0.0 END HANDLER 20 CONTINUE END HANDLER would work. Sure, the second loop won't be vectorised, but it will only be executed when the exception has occurred. Imprecise exceptions in the first loop are fine. Giles is arguing that the present vicious circle should be maintained: FORTRAN has no *standard* exception-handling scheme, so architects say "we don't have to provide for non-standard features", so computers are built where arithmetic is allowed to produce GARBAGE, so exception handling is hard to do on some machines, so FORTRAN has no *standard* exception-handling scheme. It is time we told the architects that high-speed garbage is garbage. It is important to know whether a computation has delivered correct results. It is not so important to know exactly where it went wrong: we can write our programs to switch over to slower more careful code if we really need to know.