From: rav@goanna.cs.rmit.edu.au (robin)
Subject: Re: fixed point vs floating point
Date: 1997/12/03
Date: 1997-12-03T00:00:00+00:00 [thread overview]
Message-ID: <6631a8$l6h$1@goanna.cs.rmit.edu.au> (raw)
In-Reply-To: dewar.881039951@merv
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
next prev parent reply other threads:[~1997-12-03 0:00 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-12-02 0:00 fixed point vs floating point Robert Dewar
1997-12-02 0:00 ` Joe Gwinn
1997-12-02 0:00 ` Ken Garlington
1997-12-03 0:00 ` Joe Gwinn
1997-12-04 0:00 ` Robert Dewar
1997-12-04 0:00 ` Shmuel (Seymour J.) Metz
1997-12-02 0:00 ` Robert Dewar
1997-12-02 0:00 ` Matthew Heaney
1997-12-03 0:00 ` Robert Dewar
1997-12-03 0:00 ` robin
1997-12-03 0:00 ` Robert Dewar
1997-12-03 0:00 ` Shmuel (Seymour J.) Metz
1997-12-03 0:00 ` Robert Dewar
1997-12-03 0:00 ` Matthew Heaney
1997-12-04 0:00 ` Shmuel (Seymour J.) Metz
1997-12-04 0:00 ` Robert Dewar
1997-12-03 0:00 ` Robert Dewar
1997-12-03 0:00 ` robin [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-09-29 10:25 RasikaSrinivasan@gmail.com
2011-09-29 10:49 ` AdaMagica
2011-09-29 13:38 ` Martin
2011-09-30 10:17 ` Stephen Leake
2011-09-30 16:25 ` tmoran
2011-09-30 16:52 ` Dmitry A. Kazakov
2011-10-01 11:09 ` Stephen Leake
2011-09-30 19:26 ` tmoran
2011-09-30 22:31 ` tmoran
2011-10-01 13:37 ` RasikaSrinivasan@gmail.com
2011-10-02 14:19 ` Stephen Leake
1997-11-28 0:00 tmoran
1997-11-28 0:00 ` Robert Dewar
1997-11-27 0:00 tmoran
1997-11-27 0:00 ` Robert Dewar
1997-11-29 0:00 ` Tarjei T. Jensen
[not found] <9711221603.AA03295@nile.gnat.com>
1997-11-22 0:00 ` Ken Garlington
1997-11-22 0:00 Matthew Heaney
1997-11-22 0:00 ` Tucker Taft
1997-11-22 0:00 ` Robert Dewar
1997-11-22 0:00 ` Matthew Heaney
1997-11-23 0:00 ` Geert Bosch
1997-11-23 0:00 ` Matthew Heaney
1997-11-23 0:00 ` Robert Dewar
1997-11-24 0:00 ` Herman Rubin
1997-11-24 0:00 ` Robert Dewar
1997-11-25 0:00 ` Joe Gwinn
1997-11-25 0:00 ` Robert Dewar
1997-11-25 0:00 ` Joe Gwinn
1997-11-25 0:00 ` Robert Dewar
1997-11-26 0:00 ` Joe Gwinn
1997-11-26 0:00 ` Robert Dewar
1997-12-01 0:00 ` Joe Gwinn
1997-12-01 0:00 ` Robert Dewar
1997-12-01 0:00 ` Joe Gwinn
1997-12-03 0:00 ` robin
1997-11-25 0:00 ` Matthew Heaney
1997-11-26 0:00 ` William A Whitaker
1997-11-24 0:00 ` Geert Bosch
1997-11-23 0:00 ` Tom Moran
1997-11-25 0:00 ` John A. Limpert
1997-11-25 0:00 ` Robert Dewar
1997-11-25 0:00 ` Robert Dewar
1997-11-24 0:00 ` Vince Del Vecchio
1997-11-24 0:00 ` Vince Del Vecchio
1997-12-03 0:00 ` robin
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox