Re: fixed point vs floating point

[gwinn@res.ray.com (Joe Gwinn)]

In article <dewar.881039951@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

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

Portability was not an issue in the relevant projects, 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?


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

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.


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

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.  

But, the compilers we used in those days couldn't get it *exactly* right,
so we didn't use fixed point arithmetic in Ada83.  If it had worked, we
probably would have used it, and I might well be able to remember the
details today.


Again, we are in a pointless circular discussion.  

And, I really don't see why it's necessary to deny the failings of
compilers that have been obsolete for at least a decade, for a now
superceeded language.  Surely we can find something more current and
relevant to worry about, to argue about.

Joe Gwinn