Marc.Graham@SEI.CMU.EDU (06/30/88)
A Mr. Borman claims that asking for decimal support is `thoughtless'
and that no one would use floating point computations for dollars. The
last claim is true. I am looking for fixed point decimal support.
Mr. Borman suggests a solution of counting in binary and maintaining
(implicitly or explicitly) a decimal scale. Such a solution is
functionally accurate and viable in some circumstances, but it is not
the entire story. If it were, there would be no such thing as decimal
hardware. The advantages of decimal hardware are twofold:
1. Decimal hardware typically allows for computations on much larger
numbers than the binary (fixed point) hardware; e.g. 10**31 as
contrasted to 2**32;
2. It eliminates the necessity to convert between binary and decimal
representations. If the commonly held view of commercial applications,
little calculation and lots of io, is accurate, then the savings in
conversion costs outweigh the loss in compute speed.
Marc H. Graham Software Engineering Institute
marc@sei.cmu.edu Carnegie Mellon University
(412) 268 7784 Pittsburgh, PA 15213
broman@cod.NOSC.MIL (Vincent P. Broman) (07/03/88)
In article <8806301350.AA05872@bx.sei.cmu.edu> Marc.Graham@SEI.CMU.EDU writes: >The advantages of decimal hardware are twofold: > >1. Decimal hardware typically allows for computations on much larger >numbers than the binary (fixed point) hardware; e.g. 10**31 as >contrasted to 2**32; I find it hard to conceive of a commercial application (aside from public-key encryption) which would require more than the 64 bit integers supported by VAXes and PCs with i8087s. Many systems such as Unix support infinite precision arithmetic in software. In any case, point 2 below casts doubt on the relevance of point 1. >2. It eliminates the necessity to convert between binary and decimal >representations. If the commonly held view of commercial applications, >little calculation and lots of io, is accurate, then the savings in >conversion costs outweigh the loss in compute speed. The "lots of I/O" in commercial applications is mostly unformatted I/O accessing databases, not formatted printing of account balances. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
rick@svedberg.bcm.tmc.edu (Richard H. Miller) (07/14/88)
In article <1143@cod.NOSC.MIL>, broman@cod.NOSC.MIL (Vincent P. Broman) writes: > > I find it hard to conceive of a commercial application (aside from > public-key encryption) which would require more than the 64 bit > integers supported by VAXes and PCs with i8087s. Many systems such > as Unix support infinite precision arithmetic in software. > In any case, point 2 below casts doubt on the relevance of point 1. But many of the systems are not 64 bit machines...remember that there are large number of IBM systems and other systems in which 32 bits are the common size of integers. Also, most commerical shops will not be using UNIX anytime soon to do large scale business processing. Also, many of these machines take a much longer time to execute double word integer arithmatic. > The "lots of I/O" in commercial applications is mostly unformatted > I/O accessing databases, not formatted printing of account balances. But much of the work is involved in the calculations of decimal values. There is enough of a difference that many of the mainframe architecture provide explicit architectual support for decimal operations. The cost savings in this is NOT trivial. Any system which supports business processing needs to support decimal mode processing Richard H. Miller Email: rick@svedberg.bcm.tmc.edu Head, System Support Voice: (713)799-4511 Baylor College of Medicine US Mail: One Baylor Plaza, 302H Houston, Texas 77030