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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	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
X-Google-Thread: 101deb,704fdaec147f48c
X-Google-Attributes: gid101deb,public
From: rav@goanna.cs.rmit.edu.au (robin)
Subject: Re: fixed point vs floating point
Date: 1997/12/03
Message-ID: <6631a8$l6h$1@goanna.cs.rmit.edu.au>#1/1
X-Deja-AN: 294779542
Expires: 3 March 1998 00:00:00 GMT
References: <dewar.881039951@merv>
Organization: Comp Sci, RMIT University, Melbourne, Australia.
NNTP-Posting-User: rav
Newsgroups: comp.lang.pl1,comp.lang.ada
Date: 1997-12-03T00:00:00+00:00
List-Id: <comp.lang.ada>


	dewar@merv.cs.nyu.edu (Robert Dewar) writes:

	>  > I think any attempt to automatically determine the scaling of intermediate
	>  > results in multiplications and divisions in fixed-point is doomed to failure.
	>  > This just *has* to be left up to the programmer, since it is highly
	>  > implementation dependent.

	>Joe said

	>  <<No, it isn't hopeless.  It's quite simple and mechanical, actually.  If it
	>  were imposssible, why then did Ada83 attempt it?  It's exactly the same
	>  rules we were taught in grade school for the handling of decimal points
	>  after arithmetic on decimals, especially multiplication and division.
	>  Ada83 should have been able to do it, given the information provided when
	>  the various variables types were defined.>>

	>Actually it is this paragraph that makes me pretty certain that the problems
	>may have been misunderstandings of how Ada works. First of all, it is simply
	>wrong that Ada83 attempts to determine the proper normalization (to use
	>Joe's term) of multiplication and division. Both the Ada 83 and Ada 95
	>design require that the programmer specify the scale and precision of
	>intermediate results for multiplication and division (in fact in Ada 83,
	>this specification is *always* explicit, in some cases in Ada 95 it is
	>implicit, but only in trivial cases, e.g. where in Ada 83 you have to
	>write

	>   X := Type_Of_X (Y * Z);

	>In Ada 95, this particular conversion can be omitted.

	>Secondly, it is not at all true that the rules are obvious or that they
	>are exactly the same as the "rules we were taught in grade school". If
	>you write

	>  x := y * (V1 / V3);

	>where V1 is 1.0 and V3 is 3.0, then the issue of the precision of the
	>intermediate value is critical, and no, there are no simple grade school
	>answers to answer this. I suggest looking at PL/1 for an attempt at
	>defining this, an attempt which most consider a failure.

Rubbish.  If evaluation of this expression fails, it
is because of exceeding the capacity of the fixed-point
multiplier.  It has -- incidentally -- nothing to do
with the division.

The above is the WRONG way to compute an expression
using fixed-point facilities.

You would write it x = (y * V1) / V3;

This way gives the fullest accuracy; the way suggested
x - y * (V1/V3);
succumbs to truncation error, which is duly
magnified by the multiplication! 

Incidentally, in PL/I, if the evaluation of the multiplication
overflows, it is because the intermediate precision
would be too great for the hardware unit.
The same problem would occur if you wrote:

x = y * 0.33333333333333;

If y has 1 or more decimal places, overflow may occur
because the number of places (in the product) after
the point exceeds the capacity of the hardware unit.

In PL/I, in such situations, when one or both operands
has a large number of digits, you specify the precision of
the intermediate product, using the MULIPLY built-in
function.  In this manner, you avoid fixed-point overflow.

	>As I mentioned
	>earlier, COBOL simply gives up in the COMPUTE statement and says that
	>the results are implementation dependent.

	>Robert Dewar