Re: intermediate results causing constraint errors

Re: intermediate results causing constraint errors

[Bob Duff]

In article <3bn3l9$pa2@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Richard Riehl worries about "constraint errors in intermediate results
>in expressions of mixed type"
>
>What's *that* about?
>
>Ada gives you complete control over the type of all intermediate results,

Robert,

I didn't see Richard Riehl's comment, but I don't understand your point.
If I write:

    type T is range 1..10_000;
    X: T := 10_000;
    Five: T := 5;
    Ten: T := 10;
    ...
    X := (X * Five) / Ten;

one implementation might overflow on the multiply and another might not.

It's true that there are ways to avoid this (define a wider-ranged type
first, and define T as a subtype of that), but I would say that that
requires some "Ada experience".  Furthermore, the Ada compiler won't
necessarily tell you about the problem, either at compiler or run-time
-- you'll find out when you try to port the code from a 32-bit machine
to a 16-bit machine (a rarity these days, I suppose).

>and you only get constraint error if you choose the wrong type. It would
>be wrong for *any* language not to give this kind of control. I simply
>don't see *any* problem here, and certainly I don't see a problem that
>needs the expertise of "experienced Ada" programmers to deal with it.

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: intermediate results causing constraint errors

[Bob Duff]

In article <D0Cp98.1AK@inmet.camb.inmet.com>,
Bob Duff <bobduff@dsd.camb.inmet.com> wrote:
>-- you'll find out when you try to port the code from a 32-bit machine
>to a 16-bit machine

Of course, that's a lot better than a language in which you might
*never* find out, and if you do, it's probably from some sort of nasty
crash or wrong answer!

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: intermediate results causing constraint errors

[Keith Thompson]

In <D0Cp98.1AK@inmet.camb.inmet.com> bobduff@dsd.camb.inmet.com (Bob Duff) writes:
> If I write:
> 
>     type T is range 1..10_000;
>     X: T := 10_000;
>     Five: T := 5;
>     Ten: T := 10;
>     ...
>     X := (X * Five) / Ten;
> 
> one implementation might overflow on the multiply and another might not.
> 
> It's true that there are ways to avoid this (define a wider-ranged type
> first, and define T as a subtype of that), but I would say that that
> requires some "Ada experience".  Furthermore, the Ada compiler won't
> necessarily tell you about the problem, either at compiler or run-time
> -- you'll find out when you try to port the code from a 32-bit machine
> to a 16-bit machine (a rarity these days, I suppose).

Actually, you're likely to find out when you try to port the code from
an implementation that derived T from a predefined 32-bit type to one
that derives it from a predefined 16-bit type.

Ada 83 specifies that a user-defined integer type is derived from a
predefined integer type "implicitly selected by the implementation"
so as to include the declared bounds; it doesn't specify exactly how
the parent type is selected.  I know of at least one implementation
that derives T from Integer (32 bits), and another that derives it from
Short_Integer (16 bits); both implementations have 32-bit Integer and
16-bit Short_Integer.

The behavior can also depend on whether the intermediate result is stored
in a register (typically 32 bits) or in a memory object (typically the
size of type T).

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: intermediate results causing constraint errors

[Richard Riehle]

In article <D0Cp98.1AK@inmet.camb.inmet.com> bobduff@dsd.camb.inmet.com (Bob Duff) writes:
>In article <3bn3l9$pa2@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>>Richard Riehl worries about "constraint errors in intermediate results
>>in expressions of mixed type"
>>
>>What's *that* about?
>>
>>Ada gives you complete control over the type of all intermediate results,
>
>Robert,
>
>I didn't see Richard Riehl's comment, but I don't understand your point.
>If I write:
>
>    type T is range 1..10_000;
>    X: T := 10_000;
>    Five: T := 5;
>    Ten: T := 10;
>    ...
>    X := (X * Five) / Ten;
>
>one implementation might overflow on the multiply and another might not.

   In fact, the Mil-Std 1815 ALRM explicitly alllows for this variation 
   in implementation by requiring Numeric_Error (not Constraint_Error)
   when run-time errors occur due to problems during evaluation of 
   intermediate expressions.  Check out the wording of ALRM 11.6 / 6.

    Richard Riehle 

>
>It's true that there are ways to avoid this (define a wider-ranged type
>first, and define T as a subtype of that), but I would say that that
>requires some "Ada experience".  Furthermore, the Ada compiler won't
>necessarily tell you about the problem, either at compiler or run-time
>-- you'll find out when you try to port the code from a 32-bit machine
>to a 16-bit machine (a rarity these days, I suppose).
    >
    One need not even restrict this  knotty little problem to inter-platform 
    porting.  I have used compilers which require some care in planning
    for this eventuality. 

     R. Riehle

>>and you only get constraint error if you choose the wrong type. It would
>>be wrong for *any* language not to give this kind of control. I simply
>>don't see *any* problem here, and certainly I don't see a problem that
>>needs the expertise of "experienced Ada" programmers to deal with it.
>
    Unfortunately, it is not a language issue.  The ALRM does have something
    to say about it.  But it is not forbidden by the ALRM.  And maybe that
    does make it a language issue.  This is one of those caveat emptor
    issues.  Ignore it at your peril  :-)

    Richard Riehle

Re: intermediate results causing constraint errors

[Robert Dewar]

OK, there are two issues here, and I think Bob is talking about one, and
Richard about the other.

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

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

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.

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.

Re: intermediate results causing constraint errors

[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    

Re: intermediate results causing constraint errors

[Robert Dewar]

The idea of Fortran users getting confused by the Brown model does not hold
water for a second.

Fortran has no arithmetic model, and Fortran programmers do not think
in terms of such models. The actual code generated by an Ada compiler
will be no different from that generated by a Fortran compiler with
respect to numeric operations in practice.

Remember that the Brown model has essentially ZERO effect on the generated
code of an Ada compiler, and also remember that the change to the floating
point model in Ada 9X will also in practice have zero effect on the
generated code.

As for the fixed-point "anomoly", this is only anomolous i you don't
understand fixed-point, and a good rule is not to use that which you
do not understand.

You will always get surprised if you try to use things you don't
understand, and only in that sense would I agree that Ada 83 is full of
little surprises in numerics.