Marc.Graham@SEI.CMU.EDU (06/29/88)
I was fascinated to note that in neither Ed Berard's post on Ada and commercial usage, nor in any of its responses, was the issue of Ada and decimal arithmetic mentioned. I would have thought that Ada's lack of support for decimal arithmetic is a major impediment to the use of Ada in commercial applications. Indeed, if I were asked to render a professional judgement on Ada to a commercial client, lack of decimal support would in itself be enough to reject it. Does anyone share this view? Does anyone have a solution (in the form of Ada code)? Does anyone know of a compiler which supports the rep clause: for T'small use T'delta; when delta is a power of ten? Has anyone else heard the rumor: "It'll be fixed in the next release" (of the ACVC)? Marc H. Graham Software Engineering Institute marc@sei.cmu.edu Carnegie Mellon University (412) 268 7784 Pittsburgh, PA 15213
CONTR47@NOSC-TECR.ARPA (06/29/88)
Perhaps Ada universal arithmetic is the answer to your needs. The code for Universal_Integer_Arithmetic and Universal_Rea{_Arithmetic are presented by Gerry Fisher in Ada Letters May, June 1984 pgs 6.30-6.47. I remember seeing some Fisher programs where all of the computing was done at elaboration time using universal math and the executable body was "null;". Thats one way to make the program get a universal answer but in your case for a more general solution the programmer should be able to declare objects of type Universal_integer etc. Hope this helps. regards, sam harbaugh ---------------------
broman@cod.NOSC.MIL (Vincent P. Broman) (06/29/88)
Requiring decimal arithmetic in order to support commercial applications is _so_thoughtless_. No careful programmer would compute in floating point dollars, when long integer (or long floating) counting by pennies will avoid roundoff problems. All you need are I/O routines that prefix a dollar sign and add a decimal point between the hundreds' and tens' place. 23045 => "$230.45" Simple. 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
smryan@garth.UUCP (07/01/88)
In article <1139@cod.NOSC.MIL> broman@nosc.mil.UUCP (Vincent P. Broman) writes: >Requiring decimal arithmetic in order to support commercial applications >is _so_thoughtless_. No careful programmer would compute in floating >point dollars, when long integer (or long floating) counting by pennies will >avoid roundoff problems. All you need are I/O routines that prefix >a dollar sign and add a decimal point between the hundreds' and tens' place. > >23045 => "$230.45" Simple. How do you compute 1.7% sales tax on $230.45? (You multiply the integers and divide by 1000. Dividing a binary number by 1000 is not cheap especially if the underlying hardware includes decimal arithmetic.)
sommar@enea.se (Erland Sommarskog) (07/07/88)
Marc.Graham@SEI.CMU.EDU writes: >I was fascinated to note that in neither Ed Berard's post on Ada and >commercial usage, nor in any of its responses, was the issue of Ada >and decimal arithmetic mentioned. I would have thought that Ada's lack >of support for decimal arithmetic is a major impediment to the use of >Ada in commercial applications. Indeed, if I were asked to render a >professional judgement on Ada to a commercial client, lack of decimal >support would in itself be enough to reject it. While it is true that Ada does not contain itself decimal arithmetic accurate to the last bit, it is easy to implement. Basically: Package Decimal_arithmetic is Type Fixed_point(No_of_dec : Natural) is private; -- Possibly limited -- Operations on Fixed_point, arithmetics and I/O. Private Type Fixed_point(No_of_dec : Natural) is -- for instance Record Int_part : integer; Fractional : integer; End record; End package; What you miss is that you can't have fixed point literals. 1.02 may not reliable. But this easy solved with a Set_fixed_point operation that takes two integer parameters. Someone pointed out that to count your money, you may as well count in cents. This is perfectly true. However, the problem arises when you have things like interest rates. I'm working with a commercial application for the moment. We use VAX-Pascal, so we don't have the same possibilities for abstract data types as in Ada. And when you are dealing with a percent figure, you must know whether it's 0, 2 or 4 decimals for this one. If two people interpret it differently, an error will be introduced. Being in the line of scaled integers: If one believe that this is a problem which occurs only in commercial applications, one is wrong. My project before this one was a graphical package to be used in radar systems. We used scaled integers. Due to real-time requirements we had no time for floating point calcualations. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "It all looks quite impressive really, but is it really necessary?" Radio Stars