From J.L.Schonfelder@liverpool.ac.uk Wed May 7 12:35:20 1997 Received: from pcmail.liv.ac.uk (pp@pcmail.liv.ac.uk [138.253.252.13]) by dkuug.dk (8.6.12/8.6.12) with SMTP id MAA02891 for ; Wed, 7 May 1997 12:35:16 +0200 Received: from jlspcnt [138.253.102.118] by pcmail.liv.ac.uk with smtp (Exim 1.61 #3) id 0wP441-0006Rr-00; Wed, 7 May 1997 11:35:13 +0100 Date: Wed, 7 May 1997 11:35:15 BST From: Lawrie Schonfelder Subject: Re: (SC22WG5.1371) Floating-point arithmetic To: sc22wg5@dkuug.dk Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Yes I do still exist! I follow the email but have not in general had the time to do much in the way of contributing. This exchange has prompted me to input my pennyworth. Predictable floating point is not the same thing as good floating point. IBM 370 architecture hex base floating point was predictable but an aweful design. The predictability of the arithmetic allowed very careful programmers to do some very clever things which meant in some codes very precise control of error was possible. For example some of the special function approximation codes written for this arithmetic managed to get results correct to 1 in the last place in quite extreme situations. In general however codes in this arithmetic started with a large error and by and large hex digits were lost at about the same rate as binary digits would have been and were in similar binary floating point systems. Further more the truncated Hex structure produced a bias in the errors that meant that statistical error analysis produced much larger errors. Floating point arithmetics need to be predictable, controllable, and of good quality (i.e. give optimal error behaviour for a given size of representation, the smallest error with control over rounding). Given such a FP representation the ideal numerical programming language would give the programmer access to the operational controls when they were necessary. For 99% of the time programming would be adequately served by standard FP operations employing standard "unbiased" rounding. For a small number of situations it might be necessary for the programmer to control precisely the direction of rounding. If these facilities were intrinsic to the language and the language had adequate abstraction capability, minority interest but nevertheless important datatypes and related facilities, like interval arithmetic, could be provided by appropriate modules. Such modules might well be defined as standard and might well be implemented by some suppliers as an intrinsic part of the processing system but they do not need to be part of the core intrinsic language definition. It has been my view for many years that we should not go on willy nilly adding intrinsic facilities, particularly datatypes to the language. WE should add just those intrinsic facilities and abstraction capabilities which support full smenatic extension (call it object orientation if you like). Interval arithmetic is a classic example of a type that should be handled in this way. It should not be itself a core intrinsic datatype but the functionalities necessary to allow it to be implemented within the language are absolutely essential and have much wider application than the narrow one of interval arithmetics. -- Dr.J.L.Schonfelder Director, Computing Services Department The University of Liverpool Liverpool, UK, L69 7ZF Phone: 44(151)794 3716 Fax: 44(151)794 3759