(j3.2006) (SC22WG5.4908) RE: [ukfortran] Comment on a comment on the WG5 letterballot on N1947

[Ian Chivers]

My background is maths and physics.

an si unit for a light year is

  9.46*10^12

and there are no decimal points in the 10 or the 12.

so on one hand we have the world of maths and algebra
and the other the expression of this in a programming language.

I disagree with Bill over his statement

  A sufficiently perverse 
  programmer can always cause problems.

this is not perversion. it is a translation of
an algebraic expression into a programming language.

Fortran = FORmula TRANslation

I also disagree with

  This is a problem on a system with 32-bit integers as default.  

When someone reads code the meaning of it should not be
dependent on a compiler switch.

ian

-----Original Message-----
From: Bill Long [mailto:longb at cray.com] 
Sent: 17 January 2013 13:52
To: Ian Chivers
Cc: 'sc22wg5'
Subject: Re: [ukfortran] (SC22WG5.4899) (j3.2006) Comment on a comment on
the WG5 letterballot on N1947



On 1/16/13 4:12 PM, Ian Chivers wrote:
> Integer overflow
> ================
>
> Hardware support
> ----------------
>
> Whilst the current IEEE standard doesn't say anything about integer 
> arithmetic there is nothing to stop hardware manufacturers adding 
> additional functionality to their hardware.
>

Yes, if they can justify the cost.  Some processors already include a
"multiply-upper" integer multiply instruction that will return the upper
64 bits of the 128-bit product (or half those sizes for 32-bit) which could
be checked for zero in compiler-generated code as a mechanism for 
testing for overflow in multiplies.   Though it does not work for 
addition, it is at least a partial means for implementing a check.  (At a
serious performance hit, of course.  But you would do this only for
debugging.)

> There have also been processors that have supported integer overflow 
> detection.
>

Yes, I recall the VAX had this.  Interesting, though, that the feature seems
to have not caught on.


> possible with both of these compilers to switch
> range and sub range checking on.
>
> You could for example do something similar
> to the following
>
>    day    [1..31]
>    month  [1..12]
>    year   [1900..2000]
>
> and trap invalid days, month and year values.

This seems closer to "bounds" checking where you compare values to limit 
values, none of which involved hardware overflow.   With a derived type 
and procedures for assignment and operations, you could implement this 
sort of thing in Fortran.


> Simple Fortran example
> ----------------------
>
> The following trivial program illustrates
> integer overflow on most compilers.
>
> So Bill's claim that integer overflow
> never creates problems is not a claim
> I would agree with.
>

Well, I meant to say I had not seen it.  A sufficiently perverse 
programmer can always cause problems.

I assume this is a sample program from your "don't do this" bag for 
first-time programmers.

> program ch0504
> implicit none
> real :: Light_Minute, Distance, Elapse
> integer :: Minute, Second
> real , parameter :: Light_Year=9.46*10**12

This is a problem on a system with 32-bit integers as default.  A 
"teaching opportunity" example.  Though there is obviously a problem 
from looking at the output, it would be less obvious to the beginner 
what went wrong.

On the other hand, the example is also in conflict with another 
recommendation against mixed-type expressions.  And, once the class got 
to the "syntax for real constants" section, they would hopefully write 
the initialization as 9.46e12 and avoid the problem entirely.

Even so, it is a nice example.

>
> I worked in User Support from 1978-2001 helping debug other peoples
> programs.
> I've spent quite a lot of time chasing bugs in peoples code.
>

Basically my experience as well.

Cheers,
Bill


-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101