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
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: fixed point vs floating point
Date: 1997/12/02
Message-ID: <dewar.881039951@merv>#1/1
X-Deja-AN: 294413807
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 881040012 21087 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-12-02T00:00:00+00:00
List-Id: <comp.lang.ada>


Joe says

  <<I neither know nor care if this is an Ada language design issue.  I don't
  buy and use language designs or even languages, I buy and use compilers.
  It doesn't much matter if we are today convinced or not; the decision was
  made then, based on the compilers then available.  It may be different
  today, but I don't see many people using fixed point where floating point
  is available.>>

That to me is an attitude that is undesirable. It is very important for
programmers to understand the difference between the semantics of a
language and the behavior of a specific compiler. Otherwise they will
never be able to successfully write portable code. Portable code is
code that strictly obeys the semantics of the language. This is quite
a different criterion than "works with my compiler." Many, perhaps nearly
all problems with portability when using supposeldly portable languages
(such as Ada) come from not understanding this distinction, and not being
sufficiently aware of code that uses implementation dependent features.

It is still quite unclear from your description whether the problems you
report are

  1. Language design problems
  2. Compiler implementation problems
  3. Misunderstandings of the Ada fixed-point semantics

I tend to suspect 3 at this stage.

Robert said

  > 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. As I mentioned
earlier, COBOL simply gives up in the COMPUTE statement and says that
the results are implementation dependent.

Robert Dewar