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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,183ebe04e93f0506 X-Google-Attributes: gid103376,public From: "Shmuel (Seymour J.) Metz" Subject: Re: fixed point vs floating point Date: 1997/12/03 Message-ID: <3485A850.3A92@gsg.eds.com>#1/1 X-Deja-AN: 294948864 References: Organization: EDS MS Reply-To: nospam@gsg.eds.com Newsgroups: comp.lang.ada Date: 1997-12-03T00:00:00+00:00 List-Id: Robert Dewar wrote: > So it is not at all the case that Ada83 should be able to handle fixed point > arithmetic automatically. Neither Ada 83 nor Ada 95 attempts this. As I noted, > PL/1 tried, but most people (not all, Robin characteristically dissents :-) > would agree that the attempt was a failure, Most working PL/I programmers would disagree. Strangely enough, PL/I is like Ada (or any other programming language) in that you will get unexpected results if you try to program before learning the language. Periodically the PL/I people have put together task groups to redefine the way PL/I handles precision and conversion. Invariably they have come to the conclussion that the current way is better than any of the proposed alternative. BTW, very few real programs have constructs like constant+constant/constant; usually at least one term will be a variable. Use default precision in the statement A = 1 + B/3; and the "problem" disappears? Is it perfect? No. But it's no worse than the anomlies in Ada fixed point, and those are managable. -- Shmuel (Seymour J.) Metz Senior Software SE The values in from and reply-to are for the benefit of spammers: reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com, user smetz. Do not reply to spamtrap@library.lspace.org