(j3.2006) Question about DIM

Bill Long longb
Wed Jan 13 09:50:27 EST 2016


On Jan 12, 2016, at 5:59 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:

>> I have not only seen DIM used, I have seen a bug report filed against it. 
>> The
>> user called the function with integer arguments that overflowed when the
>> subtraction was done.  The function result was negative because of the
>> overflow.  The user claimed that the Fortran standard required the result 
>> to be
>> nonnegative.
> 
> Obviously not.
> 
> <<<
> I had also thought about potential problems with integers. The current 
> wording seems to just ignore that case.
>>>> 
> 
> The same problem arises with non-IEEE reals too.  The current wording does 
> not ignore that case either (see below).
> 
> <<<
>  I suspect that we really intend something like
> 
> ?If X > Y and X - Y is representable by the type and kind of X, the result 
> is X - Y; otherwise the result is zero.?
>>>> 
> 
> Definitely not.  Apart from giving the wrong answer, it would also slow down 
> everyone's integer DIM for the sake of giving a value to an erroneous 
> calculation.  What a waste.
> 
> The "current wording" includes 13.8.1p2 which already covers the situation 
> of an out of range result for any intrinsic function, viz "shall not?.

I?m aware of that, but am not convinced it applies.  The result for DIM involves a decision:

if (X-Y > 0) then
  result = x-y
else
  result = 0
end if

One could argue that if X-Y is out of bounds, it is unreasonable to claim that X-Y > 0 evaluates to true.  Rather, in that case the result is 0, which is certainly a representable value. 

It is probably the case that no one has looked at DIM since we made X-Y>0 a valid syntax for a logical expression.  Which is why I proposed alternate wording that avoids using the expression.

Regarding performance, I don?t see any difference between including the check in the function and requiring the programmer to include checks before calling the function to avoid invalidating his whole program.   Without the internal checks, there is little point to DIM.

Cheers,
Bill


> 
> Cheers,
> -- 
> ........................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

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





More information about the J3 mailing list