More on Ada and decimal

More on Ada and decimal

[Marc.Graham]

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
                   

Re: More on Ada and decimal

[Vincent P. Broman]

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

Re: More on Ada and decimal

[Richard H. Miller]

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