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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1de1981df403322c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-12 07:34:57 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 12 Nov 2003 09:34:55 -0600 Date: Wed, 12 Nov 2003 10:34:53 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: New limited range type? References: <1068220677.950551@master.nyc.kbcfp.com> <1068224385.790621@master.nyc.kbcfp.com> <1068649222.351052@master.nyc.kbcfp.com> In-Reply-To: <1068649222.351052@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-J0JCZ1u0oxM2qGi9tloYNpHHxxiFe6cplxGl0G2YSBhQWsEWOuNZRyPXd6Aw7/MvCMTLufmYr2uAVZK!hNBDEfCM49bmHjqUB2ODXIedGI3euy9smxqkoiUhAva1Qe46lLoNyGPtWEWrhg== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:2422 Date: 2003-11-12T10:34:53-05:00 List-Id: Hyman Rosen wrote: > But in floating arithmetic, A + B - C may produce the numerically > correct result even if A + B by itself would overflow. Would this > need to be changed for saturating arithmetic? If A + B would saturate > but A + B - C (in ordinary arithmetic) would not, should the result > be required to be UPPER_LIMIT - C? No. This is a consequence of the principle in Ada that predefined operations return a value of the base type, and any constraint checks required for a subtype are done as part of the assignment operation. If bounded types were added to the RM without modifying 4.5(8&10), then if A + B is within the range of the base type, the result of A + B - C would be REQUIRED to be the mathematically correct result or UPPER_LIMIT if (A + B - C) > UPPER_LIMIT. If the mathematical result of A + B is outside the base range for the type then the permitted result set could contain additional values. But assuming that type'Base'Last > 2 * Upper_Limit, then overflow would not be an issue (even if the value of C were less than zero). Incidently this is an argument for adding saturating arithmetic to the language, as you can't do it right by overloading the math operations. In the case of a (language or implementation defined) attribute, you would have to write every calculation such as this as: X := Some_Subtype'Limit(A + B - C); Of course, that makes what is going on very clear... -- Robert I. Eachus 100% Ada, no bugs--the only way to create software.