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: 107079,183ebe04e93f0506
X-Google-Attributes: gid107079,public
X-Google-Thread: 103376,183ebe04e93f0506
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: fixed point vs floating point
Date: 1997/12/01
Message-ID: <dewar.881006262@merv>#1/1
X-Deja-AN: 294293894
References: <mheaney-ya023680002211970739180001@news.ni.net>
 <65846t$4vq$1@gonzo.sun3.iaf.nl>
 <mheaney-ya023680002311970203250001@news.ni.net> <dewar.880302541@merv>
 <65c58j$1302@mean.stat.purdue.edu> <dewar.880417337@merv>
 <gwinn-2511971025020001@dh5055083.res.ray.com> <dewar.880487594@merv>
 <gwinn-2511972139290001@dh5055083.res.ray.com> <dewar.880518760@merv>
 <gwinn-2611971945330001@dh5055143.res.ray.com> <dewar.880598918@merv>
 <gwinn-0112971245290001@dh5055193.res.ray.com>
Distribution: inet
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 881006480 7155 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada,sci.math.num-analysis
Date: 1997-12-01T00:00:00+00:00
List-Id: <comp.lang.ada>


Joe said

<<Who said we expected Ada83 fixed point types to solve all problems?  What
we hoped for was that conversion between scalings and normalizations after
arithmetic would be handled, and they weren't.  This, one could expect a
language to do.>>

Well we are still unclear as to what are language issues here, and what
are issues of bad implementation (i.e. bugs or bad implemenation choices
in the compiler), and so are you :-) In fact we still have no convincing
evidence that there were *any* compiler problems from what you have recalled
so far.

As to expecting the language to do scaling autoamtically, I think this is
a mistake for fixed-point. PL/1 tried and failed, and COBOL certainly
does not succeed (a common coding rule in COBOL is never to use the
COMPUTE verb, precisely because the scaling is not well defined).

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.

I have no idea what you mean by "normalizations". This term makes no sense
to me at all in a fixed-point context.