From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 21 Jul 93 18:13:57 GMT
From: dst17!mab@ford-wdl1.arpa  (Mark A Biggar)
Subject: Re: Can you help with fixed-point arithmetic?
Message-ID: <1993Jul21.181357.12063@wdl.loral.com>
List-Id: <comp.lang.ada>

In article <1993Jul21.082925.3193@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) wr
ites:
>If you want to add both days and partial days, give this "+" a third
>parameter of type Duration.  Again, detect the possible overflow and
>propagate a carry into DAY.  Be careful -- there are subtleties in
>detecting the overflow.  Consider
>	if SECONDS + Increment > 86400.0 then
>Your compiler is not incorrect if it lets Constraint_Error be raised in
>evaluating the sum.  It's also not incorrect if it does the comparison
>correctly, dealing with an intermediate result (the sum) outside the
>range of type Duration.  In the worst case you may have to just do the
>sum and detect the Constraint_Error.

Sense, Increment is of type Duration (and probably positive as well) why
not just code the above condition as:

	if SECONDS > 86400.0 - Increment then

which correct detects the overflow and never raises Constraint_Error.
If Increment can be negitive, then you have to split the code into two cases
to handle the Carry vs Barrow cases after the call the Split anyway, so you
might as well use two different overflow tests.

It is almost alway possible to write an overflow test for addition in such
a way as to never raise Constraint_Error.  Dectecting overflow of multiplcation
is much more difficult.

--
Mark Biggar
mab@wdl.lroal.com