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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,18f7f6e041b3e0bf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-16 08:21:14 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Decimal Floating types was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question Date: 16 Aug 2002 08:21:14 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0208160721.7ae05a3@posting.google.com> References: NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1029511274 16537 127.0.0.1 (16 Aug 2002 15:21:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 16 Aug 2002 15:21:14 GMT Xref: archiver1.google.com comp.lang.ada:28108 Date: 2002-08-16T15:21:14+00:00 List-Id: "Robert C. Leif" wrote in message news:... > Since COBOL does not have a decimal floating point, COBOL > programmers, who still do most of the financial > applications, have not had a chance > to try it!. And why do you suppose COBOL does not have this? It is because the COBOL standards committee does not consider it worth adding. What does Robert Leif know that the committee does not :-) The point is that in financial calculations, you either want absolute error control, e.g. in computing yields of bonds, where very often the instruments specify the exact algorithm in terms of fixed-point decimal. Or you want approximate results rounded. There is no requirement for mathematically accurate rounding for decimal floating-point that I am aware of, so in practice if you are doing approximate calculations, it is just fine to do things in binary with sufficient precision and then round the binary to decimal. Yes, there are marginal cases where the double rounding can lead you to be "off" by 1 ulp but there are no situations where this would matter. Furthermore, as I noted before, there is no point in embedding such a feature into the language. If you want decimal floating-point, just use a library, there are many, that supply this capability and make calls to this library. That's what the compiler would do anyway. COBOL programmers can perfectly well use such libraries. COBOL is perfectly capable of calling library routines! This seems a perfect example of a "requirement" generated out of the blue, without full understanding of the actual problem space. The COBOL committee has been extremely adventurous in extending the language (the COBOL object model is for example more ambitious than that of C++ or Ada). If there was the slightest good argument for adding decimal floating point to the language, it would have been seriously considered.