From owner-sc22wg5@open-std.org  Sat Oct  8 16:53:52 2005
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-domo2
Delivered-To: sc22wg5-domo2@open-std.org
Received: by open-std.org (Postfix, from userid 521)
	id 04D56152BC; Sat,  8 Oct 2005 16:53:51 +0200 (CET DST)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66])
	by open-std.org (Postfix) with ESMTP id 0D518113B6
	for <sc22wg5@open-std.org>; Sat,  8 Oct 2005 16:53:49 +0200 (CET DST)
Received: from mx3.liv.ac.uk (mx3.liv.ac.uk [138.253.100.181])
	by dkuug.dk (8.12.10/8.9.2) with ESMTP id j98EqqbU026504
	for <sc22wg5@dkuug.dk>; Sat, 8 Oct 2005 16:52:58 +0200 (CEST)
	(envelope-from j.l.schonfelder@liverpool.ac.uk)
Received: from mailhub1.liv.ac.uk ([138.253.100.94])
	by mx3.liv.ac.uk with esmtp (Exim 4.52)
	id 1EOFN6-0004EZ-EH
	for sc22wg5@dkuug.dk; Sat, 08 Oct 2005 15:08:20 +0100
Received: from localhost ([127.0.0.1] helo=mailhub1.liv.ac.uk)
	by mailhub1.liv.ac.uk with esmtp (Exim 4.52)
	id 1EOFN6-0006Ib-BJ
	for sc22wg5@dkuug.dk; Sat, 08 Oct 2005 15:08:20 +0100
Received: from host217-42-104-141.range217-42.btcentralplus.com ([217.42.104.141] helo=[192.168.0.2])
	by mailhub1.liv.ac.uk with esmtpsa (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.52)
	id 1EOFN6-0006IY-5Z
	for sc22wg5@dkuug.dk; Sat, 08 Oct 2005 15:08:20 +0100
Date: Sat, 08 Oct 2005 15:08:19 +0100
From: "J.L.Schonfelder" <j.l.schonfelder@liverpool.ac.uk>
To: WG5 <sc22wg5@dkuug.dk>
Subject: Re: (j3.2005) (SC22WG5.3318) SC22 meeting
Message-ID: <CFBBE0CF063B9A4EA6240E94@[192.168.0.2]>
In-Reply-To: <20051007143249.EA5CB13E6D@open-std.org>
References:  <20051007143249.EA5CB13E6D@open-std.org>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0 () 
Sender: owner-sc22wg5@open-std.org
Precedence: bulk



--On 07 October 2005 15:33 +0100 John Reid <j.k.reid@rl.ac.uk> wrote:

> 1. Resolution 05-08: Revision of IEEE 754 Standard for Floating-Point
> Arithmetic
>
> We are asked to provide our input regarding requirements for our decimal
> floating-point work. The Cobol convener gave me to understand that the
> current problems are associated with choosing the base: 10 or 1000. Cobol
> very firmly wants 10. I said that we had no strong views on this and
> would probably support whatever the standard finally says. Does anyone
> disagree?
>
A base 10 arithmetic and a base 1000 are commensurate in that the 
conversion from one to the other is almost trivial and exact. However there 
are some significant differences. 1000 is clearly advantageous from an 
efficiency of implementation point of view. A single base 1000 digit (equiv 
to 3 decimal digits) can be very efficiently packed into 10 bits (1023). If 
one then uses a standard fixed precision representation and a normalisation 
to base 1000 exponent a very straight forward arithmetic results. This 
unfortunately suffers from the wobbling word length effect common to large 
base arithmetics, c.f. the well known effect with HEX floating point verses 
binary in the same wordlength. The problem with base 1000 is of course 
greatly compounded. For example, with a normalisation with leading digit 
non-zero (standard practice) it would be possible that only one of the 
possible three decimal digits representable would be determined and hence a 
potential 2D loss of precision. Or to put it another way to guarantee 6 
decimal digits of accuracy you would need to retain 3 base 1000 digits. 
This effect would be likely to negate the efficiency gain by using base 
1000 in the first place.
The probable solution would be to operate with a base 10 normalisation but 
to use a representation that effectively packed 3D into each 10 bits. I 
remember Kahan advocating such a system about 30 years ago.
My view is that I believe the Cobol people are probably right but whether 
for the right reason is not clear. I do not think a true base 1000 
arithmetic is desirable but a mixed system with base 1000 digit packing but 
base 10 normalisation is entirely possible and if Kahan was right (he 
usually was) the complications involved were not so great and they could 
all be implemented in silicone so as to be hidden from the average user.



--
Dr. Lawrie Schonfelder
Honorary Senior Fellow, University of Liverpool
Home: 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN
Phone: +44 (151) 625 6986 
