Path: utzoo!attcan!uunet!husc6!im4u!oakhill!davet
From: davet@oakhill.UUCP (David Trissel)
Newsgroups: comp.arch
Subject: Re: negative addresses (now 64 bit arithmetic)
Message-ID: <1327@oakhill.UUCP>
Date: 17 May 88 09:12:48 GMT
References: <2393@uvacs.CS.VIRGINIA.EDU> <9485@apple.Apple.Com> <965@cresswell.quintus.UUCP> <11592@ut-sally.UUCP>
Reply-To: davet@oakhill.UUCP (David Trissel)
Organization: Motorola Inc., Austin Tx.
Lines: 24
Posted: Tue May 17 04:12:48 1988

In article <11592@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:

>Now, if we designed computers so integer word sizes were large enough to
>hold the largest number we now use in floating point (ca. 2^512 or so)
>then we wouldn't need a complex floating point system -- just good,
>fast (wide) integer operations.  And I could count events without
>constantly looking over my shoulder for problems.

Having worked in the past as a systems programmer at both large commercial
as well as number-crunching installations I always found it interesting that 
COBOL was the only language I knew of which mandated support for an extended
integer data type of more than 32 bits.  (Out of curiousity I just HAD to
look at the source code for the 64 bit integer square root routines!  Yes
COBOL does support sqrt(), believe it or not.) 

That was about 10 years ago and the only thing I remember is that 
the COBOL spec required that this integer data type be able to exactly 
represent at least 19 (or was it 18?) decimal digits of precision.

It's obvious financial arithmetic requires precise results.  But I
never understood why the other languages favored by the number crunching folks
never supported a larger integer type.  Is there really no use for this?

 -- Dave Trissel  ut-sally!im4u!oakhill!davet