Re: fixed point vs floating point

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Joe said:

<<Portability was not an issue .. and so was never raised.

  However, now that you have raised the issue, some comments:  Portability
  is less important than workability.  And, we were always assured that use
  of Ada guaranteed portability.  Apparently that was a lie; we also need to
  be Ada experts to achieve portability?  Just like all other languages?

I always find it amazing that anyone would ever have, even for a moment,
thought that using an Ada compiler would somehow guarantee that their code
was portable. And it is even more amazing that someone with this strange
viewpoint would turn around later and complain that they were lied to.

Really Joe, surely you know that you cannot achieve portability without
some care on the programmer's part. Yes, it is true that programs can be
written in Ada that are portable. BUT, and this is a big BUT, you do have
to know the language. No, you do not have to be an Ada expert, but you DO
have to know the language, and you do have to know the language well enough
so that you know the difference between Ada the language, and what your
compiler happens to implement for implementation dependent constructs.
If you don't know Ada, and you don't care about portability (as was
apparently the case in your project -- by don't know Ada here, I mean
that you do not bother to carefully study the definition of the language),
then you definitely CANNOT write portable code in Ada.

If anyone ever promised you that using an Ada compiler would guarantee that
your programs they were an ignorant fool, and it surprises me that anyone
would believe such nonsense. Certainly you never heard anything of the kind
from anyone who knew anything about the language!

<<Well, too many people failed to make it work for #3 to be a likely cause,
  and the compilers of the day are known to have been a work in progress.

  This has degenerated into a pointless yes-you-did, no-I-didn't cycle.
  Suffice it to say that we disagree on a minor issue too far in the past to
  remember the details clearly enough to have a useful debate, assuming of
  course that the limitations of 1980s compilers have any relevance
  whatsoever in the 1990s.>>

I have NO clear idea what you did or didn't do. You made certain claims in
your original post, and I was interested to see if you could substantiate
them. It seems that really you can't, which I don't find too surprising,
because they did not make much sense to me. But I did not want to jump to
that conclusion, which is why I was trying to find out more details.

<<Well, you are obsessing on the fact that I don't recall ten years later
  all the details of how to do fixed point arithmetic in Ada83, which we
  never used except to test.  And, you are proving my basic point, that with
  all that user-supplied information, Ada83 should be able to handle fixed
  point arithmetic.  This is just some added information, clearly not
  absolutely required information, because Ada95 no longer always requires
  it.>>

No, you did not read carefully. Ada 95 absolutely DOES require programmers
to provide intermediate precision precisely. It is just that in certain
cases, this can be implicit in Ada 95. For example

   x := y(A * B) + y(C * D);

the conversions to type y here, specifying the intermediate scale and
precision are required in Ada 83 and Ada 95, and those are the important
cases. The case which has changed is relatively unimportant:

   x := y(A * B);

Ada 83 required the explicit conversion here, but since the most likely case
is that y is the type of x, Ada 95 allows a shorthand IN THIS SITUATION ONLY
of leaving out the type conversion.

So it is not at all the case that Ada83 should be able to handle fixed point
arithmetic automatically. Neither Ada 83 nor Ada 95 attempts this. As I noted,
PL/1 tried, but most people (not all, Robin characteristically dissents :-)
would agree that the attempt was a failure, for example the rule that requires

   22 + 5/3

to overflow in PL/1, where

   22 + 05/3

succeeds, is hardly a masterpiece of programming language design, but to be
fair, PL/1 was really trying to solve an impossible problem, so it is not
surprising that its solution has glitches. Indeed the reason that 22 + 5/3
overflows bears looking at, since it is a nice example of good decisions
combining to have unintended consequences.

Question 1: What should be the precision of A/B?
Answer: The maximum precision possible guaranteeing no overflow.

Question 2: What happens when two numbers with different scales are added?
Answer: One is shifted left to line up decimal points (we do not want to
         lose pennies!)

Now 5/3 is a case of one digit divided by one digit, which can have at most
one digit before the decimal point (for the case of 9/1), so the result is

   1.6666666666666666666666666667

Where by definition the number of digits is the maximum number of digits that
can be handled.

Now we add the 22 and

   1.6666666666666666666666666667
  22.0000000000000000000000000000

oops, the 2 fell out the left hand side.
But if the literal is 05 (with a leading zero), then it is two digits, and we
get:

  01.666666666666666666666666667
  22.000000000000000000000000000

It is really hard to get these rules to behave well without anomolies of this
type. To my taste no one has succeeded, and the decision in Ada 83 and Ada 95
to make the programmer specify intermediate precision and scaling seems
exactly right.

<<But, the compilers we used in those days couldn't get it *exactly* right,
  so we didn't use fixed point arithmetic in Ada83.>>

There goes that claim again, but we still have seen no evidence or data to
back up this claim, other than "that must have been it, otherwise we would
not have thought it was the case". NOT very convincing!

Incidentally, if you want to read more about fixed-point issues in Ada,
a good starting point is the special issues report on Ada fixed-point
that I did for the Ada 9X project.