On Jan 7, 2012, at 13:25, John Gilmore wrote:
>
> <begin snippet>
> Likewise, the arithmetic IF or use of a single-argument signum with
> two comparands requires a subtraction which may result in overflow for
> extreme comparand values.
> </end snippet>
>
> I am not quite sure what a 'single-argument signum' with two
> comparands is. For such common FORTRAN as
>
One should not consider automatically replacing:
IF ( A .LT. B ) GOTO 100
IF ( A .EQ. B ) GOTO 200
IF ( A .GT. B ) GOTO 300 /* my putative optimizer will fix it! */
with
IF ( A - B ) 100, 200, 300
or even:
S = SIGNUM( A - B )
...
Lest it be preceded, unbeknownst to the programmer with
assignments to the 31-bit operands A and B:
A = 2000000000
B = -2000000000
> | float*4 x
> | . . .
> | if (x) 12, 14, 16
> | . . .
> | 12 <code for negative x>
> | . . .
> | 14 <code for zero x>
> | . . .
> | 16 <code for positive x>
>
> There is of course a subtraction in the compiled code, but in my
> experience it is an innocuous one: zero is subtracted from x to set a
> condition code or the like. (When x is replaced by a non-degenerate
> expression overflow may of course be a problem, as it is in all
> arithmetic.)
>
> There are of course things that can be done to minimize such problems
> Kernighan and Ritchie did not do it in their example. They wrote
>
> | mid = (low+high) / 2;
>
> but
>
> | mid = low + (high - low)/2 ;
>
Beware of truncation in integer division; the forms are
not equivalent.
> all but eliminates subscript-arithmetic overflow problems when, as in
> C, obligatory zero-origin subscripting is used. It is also possible
> to go much further down this path, but I will forebear.
> come, I have always suspected that academics---With a few conspicuous
> exceptions they are poor programmers---would like to avoid teaching
> programming at all. Then---wish being father to thought---they
> imagine that a programming language that makes the teaching of
> programming all but unnecessary has been made available to them.
>
I suspect you sometimes categorize me with those academics.
If so, to dispel that notion you need only look at some
of my shell script or Rexx code, which not only would
likely be found objectionable by such academics, but
also by some of my peers. I feel free to use any feature
of the language definition, while striving earnestly not to
transgress its specification, and paying scant attention to
arguments such as, "That construct would be incomprehensible
or, worse, misleading to a {FORTRAN|Pascal|COBOL|Assembler|
...} programmer." I freely modify DO control variables
within the loop; when the FORTRAN programmer objects, I
counter by citing the clear specification of the semantic
in the Rexx standard -- RTFM.
FORTRAN programmer's shell script:
command_1
RC=$?
if test $RC -eq 0 # Honest; I've seen it!
then command_2
else command_3
fi
My shell script, which the FORTRAN programmer deems recondite:
if command_1
then command_2
else command_3
fi
-- gil
