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, LOTS_OF_MONEY 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: Al Christians Subject: Re: financial computations Date: 2000/05/10 Message-ID: <39192EB2.C4042B3A@easystreet.com>#1/1 X-Deja-AN: 621495514 Content-Transfer-Encoding: 7bit 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> <8fah2b$lv0$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsabuse@supernews.com Organization: Trillium Resources Corporation MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-05-10T00:00:00+00:00 List-Id: Robert Dewar wrote: > > The relevant codes require adherence > to the prescribed approaches, and specify penalties for > non-compliance. > Can you give a specific example? > > 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 I've yet to see a set of legal requirements that required anywhere near the 18 or so digits that my FPU will support. If rounding or truncation at a certain digit is mandated by the requirements, I can do that explicitly, although approximately. There is some little bit of round-off or truncation error, but all that is happening down around $0.0000000000001 on a million-dollar bond, so the chance that it has any effect on any number actually looked at or used by anyone is way less than my chance of winning the 300 megabuck lottery, and I didn't even buy a ticket. If you have any specific example where that's not so, I'd love to see it. > > The problems are very much worse than simply losing a penny! > Can you give a specific example? > Well I have to admit that I set a bit of a trap there that you > fell right into. How do you live with yourself? > 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. That which is not elsewhere defined is defined by an implementation. > There is definitely no need for ** to be very very slow, > given that it can perfectly well be done in floating-point. > So why was it so slow? Were you pushing data into the FPU one byte at a time? Using a slow FPU emulation library? Or doing the exponentiation in fixed point as some kind of a power series? BTW, for everything else, Realia's performance was good, but not for exponentiation. Questions for the Supreme Court: (1) If I do the calculations using FPU emulation on a machine that has only fixed-point instructions, is that legal or not legal under the statutes in question? (2) If I write a program that I think is fixed point to comply with the law, but my compiler or firmware was written by some genius who knows how much faster the FPU is, so he uses it behind my back, will we both go to jail? > 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++). I've known several that strongly discouraged it, but only because it was so slow. > 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 :-) > BTW, that reminds me, to get back on topic, has the implementation of Comp-3 packed decimals in Gnat been changed yet so that the binary representation will be compatible with the likes of Realia? Seems that Gnat implemented these as an array of nibbles (4-bit digits), and one can't make any assumptions about the position of nibbles in an array within a byte in Ada, and Gnat actually mapped the nibble with the lower subscript to the least significant bits of the byte, but your packed decimal routines did make the opposite assumption. I have code to fix this around here somewhere if you'd like to see it. Al