Re: intermediate results causing constraint errors

[riehler@ajpo.sei.cmu.edu (Richard Riehle)]

In article <3c1pk6$jk4@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>OK, there are two issues here, and I think Bob is talking about one, and
>Richard about the other.
>
    "Between the idea and the reality falls the shadow..."
                                  T.S. Eliot 


>From what I understand of Richard's position, he would like a guarantee
>that no intermediate results cause constraint error ever. That seems
>quite impractical, since it would result in harmless expressions like
>
>   Mid := (hi + lo) / 2
>
>generating calls to runtime multiple precision packages etc. which you
>certainly don't want. I just sent Richard a much more detailed discussion
>of this point (Richard, feel free to repost that response here if you think
>it is useful to do so).

    I did draft a response to your response, Robert.  However, I think
    there is enough agreement between us on this that we can open it
    up here with existing material.  

    Your message, here, confirms my original point that one needs to be
    aware of this sort of thing when dealing with numerics. 
    I don't require any sort of guarantee, just a clear idea of whether 
    my program is likely to behave as I hope it will.

>
>Bob is noting that the optimization rules (the infamous 11.6 section of
>the RM (which was briefly 11.7 in 9X, but this section number is so well
>known, that people complained, and now it is once more 11.6 again in 9X :-)
>
>allow compilers to avoid giving the constraint error if they give the
>"right result".

      ALRM 11.6 is also what I was referencing in my earlier reply, but I guess
      I did not make myself clear. 
>
>This of course introduces non-portabilities, but if one insisted that
>intermediate results always be checked it would generate annoying extra
>code. Consider:
>
>   X := A * B / C;
>
>on many machines multiply and divide handle double length results free, so
>the check would make things inefficient.
>
     Exactly!  I don't want intermediate results to be checked in this way.

     ... but in the real world of real compilers ...

     When I start a new job, using a new Ada compiler (which is sometimes
     a very old compiler), I like to feed it some simple litle programs to
     see what will happen. For example:


            with text_io;
            procedure Hollow_Men is
               D : Integer := Integer'Last;
               R : Integer;
            begin
                R := (2 * D) / 3;
            end Hollow_Men;

     which often causes this program to crash, not with a whimper but a bang,
     and a message Numeric_Error (yes, I know about Section 4.9 of AI-387,
     but  some compilers don't) or Constraint_Error.

      
>It would be nice if Ada compilers at least had an option to guarantee
>that they checked all intermediate results, so you could be sure your
>code was portable, although there are still problems with different
>base types for integers.

     Agree.  But we all live in the real world.  As I understand 11.6,
     the compiler is allowed to check intermediate result, but not 
     required to do so.  And if it does check intermediate results, it
     must give you the correct answer (within the precision expected),
     but it may raise a Numeric_Error / Constraint_Error.  

     My original comment, an aside really, was to note that one must be
     aware  of such things, not that this was pathological.

     Summary:

     Ada 83 is filled with little surprises in its treatment of numerics.
     The famous example of adding 0.01 to itself 100 times and getting
     0.78 (in fixed point) is one of these.  

     People who work heavily in numerics sometimes get frustrated with Ada
     if they are used to FORTRAN.  The Brown model for floating point has
     proven  itself to be less than satisfactory.  I would guess that there
     are good reasons why Ada 9X has abandoned Brown.

     This is also why I agreed with you, Robert D., when you said it
     was not useful to define too many types when doing intensively
     computational computing.

     Richard Riehle