Re: fixed point vs floating point

[rav@goanna.cs.rmit.edu.au (robin)]

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

	>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.

	> [snip}

	>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,

Do you have something better?

This silly example has been bandied about on quite a few
occasions in cases like this so "show" that the conversion
rules for fixed-point working in PL/I are silly or not
optimum.

In fact, what you are doing is adding two very large nunmbers,
both of which are at the capacity of the decimal arithmetic
unit.

i.e. You are asking, what is 25.00000000000000 + 1.33333333333333 ?
on a machine with 15 digits of precision.

Of course it will overflow.  That's the nature of fixed-point
working.

so as to have at least one fewer digits after the point. (there's
a standard function for this.)
nd BTW, PL/I detects the overflow, should it occur,
and tells you.


	> 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

Pl/I doesn't round up.

	>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.