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,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-28 20:13:22 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!newsfeed2.earthlink.net!newsfeed.earthlink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3ED57AC3.6000608@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Saturated Math References: <3ECFF541.1010705@attbi.com> <3ED0B820.5050603@noplace.com> <3ED2096F.3020800@noplace.com> <3ED353BE.40605@noplace.com> <3ED4A323.3000909@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc04 1054177997 24.62.164.137 (Thu, 29 May 2003 03:13:17 GMT) NNTP-Posting-Date: Thu, 29 May 2003 03:13:17 GMT Organization: AT&T Broadband Date: Thu, 29 May 2003 03:13:17 GMT Xref: archiver1.google.com comp.lang.ada:37971 Date: 2003-05-29T03:13:17+00:00 List-Id: Robert A Duff wrote: > It seems to me that a saturating arithmetic ought to "stick" at > infinity. If you say "X + 1000", and that returns the max, then > subtracting 1 from it should return the max, not max-1. Others have > said otherwise, and I wonder why. All this discussion has convinced me is that any attempt to add saturating integer types to Ada is definitely a bad thing. If a user implements the type of saturating arithmetic he needs, that is relatively safe. At least he or she will know what happens and where. But adding a predefined saturating type to Ada would be like giving a loaded gun to a baby. For every problem it solved, a dozen others would be papered over and hidden. A case might be made for adding optional NaN values to fixed-point types, especially decimal types. As for floating point, I think GNAT allows users to "take advantage" of the saturating modes of IEEE floating point. The idea makes my skin crawl slightly, but that is normal when I see floating point. Seriously, there are many cases where error analysis for floating point code gives reasonable results. The creepy feeling comes when either the analysis obviously hasn't been done or the territory is full of land mines. So the real problem is that cases where the error analysis is tough get pushed into floating point, when using integer arithmetic or fixed point is probably impossible anyway. The latitude and longitude discussion we just had was a good example. It takes about a minute to work out the worst case error for 32-bit fixed point. The suitability of (24-bit) floating-point will depend on the accuracy you need and where you are. (Degrees of longitude get smaller as you approach the poles, so the worst case is just above 32.0 degrees of latitude or below -32.0 degrees. (Assuming decimal degrees.) Degrees of latitude are the same size everywhere--modulo the Earth's deviation from spherical. So the worst case in floating point, will be latitudes greater that 64.0 degrees or less than -64.0 degrees. If I felt that people who used 32-bit floating point latitudes and longitudes had done that analysis, I'd sleep a lot more comfortably. Especially on overseas flights that might cross that magic 64 degree line. (Just below the Artic circle, or above the Antartic circle.)