From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c872b4c479fe6a9b X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: financial computations Date: 2000/05/10 Message-ID: <8fah2b$lv0$1@nnrp1.deja.com>#1/1 X-Deja-AN: 621383175 References: <391725AA.4F68ED72@gmx.de> <39182D26.F4FDB0F8@quadruscorp.com> <8f93qg$1g9$1@nnrp1.deja.com> <39182A7C.C1358EE2@easystreet.com> <8f9o7c$q3o$1@nnrp1.deja.com> <3918A193.9800E973@easystreet.com> X-Http-Proxy: 1.0 x27.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Wed May 10 02:21:11 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-05-10T00:00:00+00:00 List-Id: In article <3918A193.9800E973@easystreet.com>, Al Christians wrote: > Robert Dewar wrote: > > in several contexts, including bond interest > > calculations, the calculation of interest must be done precisely > > in decimal arithmetic, with specified truncation or rounding > > semantics. You can only approximate this in floating-point. > > That's not quite the same thing as illegal, is it? Actually, yes it is. The relevant codes require adherence to the prescribed approaches, and specify penalties for non-compliance. > With 64-bit mantissae available in several programming > languages, > including Ada according to GNAT, if I know the rules, I can > approximate this stuff for a million lifetimes before I lose > a cent. That's quite incorrect, because you need to control whether each operation truncates or rounds, and that is not possible with floating-point, since the floating-point engine itself is typically set to round all the time, and as I am sure you know rounding followed by truncatation is not equivalent to truncation. Also everything has to be done as if it were in scaled decimal. You cannot use floating-point binary to accurately represent scaled decimal (you might want to look at what Kahan has to say about decimal vs binary arithmetic, there are a LOT of surprises for the uninitiated there). > Realistically, I expect that when I do lose that penny > there will be some character at hand who will point out the > error and gloat without mercy. The problems are very much worse than simply losing a penny! > > COBOL has no defined semantics for exponentiation, so I do not > > know what you are talking about here at all. > > > Let me practice some mentalism, go a little deeper into my > catatonic trance, and look deep into our past .... I see a > COBOL compiler ... I see ADD ... I see SUBTRACT ... I see > MULTIPLY ... I see DIVIDE ... but I don't see EXPONENTIATE. > Could be you are right about this one, Robert. But wait, > what's this? I see COMPUTE ... It has expressions ... It > has arithmetic operators ... It has +, -, /, *, and, aha, ** > for exponentiation ... and ** is very, very slow. When I wake > up it will be almost finished .... Well I have to admit that I set a bit of a trap there that you fell right into. I assure you I would not have made the statement about ** being undefined without knowing what I was talking about (I know COBOL rather well, see below) :-) COMPUTE has undefined arithmetic semantics. It is for example quite fine to use floating-point for all calculations in COMPUTE. There was even talk of REQUIRING the use of IEEE long form floating-point for COMPUTE in the 9x standard, but that was too controversial. There is definitely no need for ** to be very very slow, given that it can perfectly well be done in floating-point. However, many (most?) COBOL shops deprecate, or even forbid the use of COMPUTE completely precisely because it has undefined semantics (just like Fortran, or C, or C++). That's an important difference with the verbs ADD SUBTRACT MULTIPLY DIVIDE which have precise implementation-independent semantics. So I am afraid your catatonic trance is not serving you well. COBOL is a fairly complex language. Few know it really well from a language definition point of view, and the subset of people who really know COBOL *and* Ada 95 is even smaller. By the way, in case people don't know I was one of the principle authors of Realia COBOL, one of the main PC based COBOL compilers, now marketed by Computer Associates, so I am indeed a member of that smaller subset :-) Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy.