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 06:04:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news-FFM2.ecrc.net!fu-berlin.de!uni-berlin.de!55.74.203.62.dial.bluewin.CH!not-for-mail From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: Saturated Math Date: Wed, 28 May 2003 15:02:44 +0200 Organization: JeLlyFish software Message-ID: References: <3ECFF541.1010705@attbi.com> <3ED0B820.5050603@noplace.com> <3ED2096F.3020800@noplace.com> <3ED353BE.40605@noplace.com> <3ED4A323.3000909@noplace.com> NNTP-Posting-Host: 55.74.203.62.dial.bluewin.ch (62.203.74.55) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: fu-berlin.de 1054127040 5138748 62.203.74.55 (16 [175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:37903 Date: 2003-05-28T15:02:44+02:00 List-Id: Marin David Condic wrote: >Vinzent Hoefler wrote: > >> Suppose you have an expression like: >>=20 >> X :=3D X + 4 - 4; >>=20 >> (Those fours might not be actual constants) >>=20 >> What would be the result then? >>=20 >Imagine it was a garden variety integer with the same range. What does=20 >the ARM say it would do? IIRC such constructs *may* raise an exception if the [intermediate] result cannot be represented (in the base type, I think). So the result is either the correct one or you get an exception. Well, let's read the ARM... mmh, yes, I would interprete 3.5.4(20) and 3.5.4(24) in that way. >What if it were a modular type with wraparound=20 >semantics? No difference, the result is defined and the same in both cases. It doesn't matter when you apply the modulus-operation: "((a mod c) + (b mod c)) mod c" is always the same as "(a + b) mod c". So the order of evaluation is of no concern here. Let's suppose there would be a similar operator call sat for saturation, this wouldn't hold true no longer: "((a sat c) + (b sat c)) sat c" is *not* the same as "(a + b) sat c". So the result depends on where and when you saturate the subexpressions. >My suggestion would be that we look for the pages that define behavior=20 >on numeric types, copy them, change the type names to something=20 >indicating "Saturated" and wherever the ARM says "raise an exception" >insert "saturate in the direction of the limit exceedence." Mmh: (20) |For a saturated integer type, the result is saturated in the direction |of the limit exceedence by the execution of an operation that cannot |deliver the correct result because it is outside of the base range for |that type. Hmm. *Might* be ok. Now a changed (24): |For the execution of a predefined operation of a saturated integer |type, the implementation need not saturate in the direction of the |limit exceedence if the result is outside the base range of the type, |so long as the correct result is produced. ;) Well, I think the problem here is: On "normal" Integers it may a) raise an exception b) gives the proper result So there's no real ambiguity (although I must admit, different implementation might slightly differ in their behaviour). With modular types there is no problem at all, with the example above it would wrap around twice, still delivering the same result. But with saturated integers it is possible to have more than a single result. So which result is supposed to be the correct one? IMO this would introduce a *very* ambiguous ambiguity. How would you resolve that without forcing the order of expression evaluation, supposed you also want to have the usual integer operations on that type? Perhaps by saying that the result of expressions involving saturated integer types is always evaluated within type root_integer and that the saturation then only applies on assignment? Note that this then should also raise an exception if the intermediate result cannot be represented anymore in root_integer or so (depending on how good the machine is with integer math). But raising an exception on saturated integer types is kind of weird, this is the last I would expect from it. >> Yes. IMO is has too many bad implications like effects on dependcy >> with expression evaluation order. >>=20 >No more so than you already have for the type Integer or Float or any=20 >other type. Well, as long as you only allow simple expression like A + B this is ok. The problem arises when you say A + B + C. >You're merely expressing a different accommodation for=20 >bounds exceedence. Yes, the intention is very clear. >>>Still, it seems like a useful feature for some kinds of jobs. >>=20 >> Well, yes. But it's not an Ada-like feature, is it? >>=20 >How is it any less Ada-like than any other numeric type? It introduces an ambiguity that clearly would need to be solved first. Vinzent. --=20 Parents strongly cautioned -- this posting is intended for mature audiences over 18. It may contain some material that many parents would not find suitable for children and may include intense violence, sexual situations, coarse language and suggestive dialogue.