Programming language failings [was Re: strangest systems I've sent email from]

[Jerome H. Fine]

 >Dave Wade wrote:

>Fortran has an EQUIVALENCE statement, COBOL has redefines. Both allows the
>subversion of types at the drop of a hat.
>
I can think of two examples which were not so much subversion of types
as they were a lack of language flexibility:

(a)  Very early in my FORTRAN experience, I needed to calculate
       values to solve a set of differential equations.  The calculations
       could all be done using ordinary REAL floating point variables.
       However, the precision required to retain sufficient accuracy
       over the range of the solution required the state variables to be
       held as DOUBLE  PRECISION variables.  The simple solution
       was to define the increments to be added to the state variables
       as both REAL  and  DOUBLE  PRECISION and to use the
        EQUIVALENCE statement for both.  The state variables were
        managed in the same manner.  When the increments were being
        calculated, the REAL variables were used.  When the increments
        were being added to the state variables, DOUBLE  PRECISION
        were used.  In order to determine that this was a reasonable
        method, at one point only DOUBLE  PRECISION variables
        were used to see if the overall results were different.  By using
        only REAL variables during the calculation of the increments,
        calculation times was substantially reduced without sacrificing
        any overall accuracy since the increments were always a factor
        of a million or more less than the state variables.  As just one
         example, one state variable was a distance of about 20,000,000
         feet and each increment was at the most less than one foot.  It
         sufficient to calculate the increment with a REAL variable, then
         switch to DOUBLE  PRECISION when the increment was
         added to the state variable.  At the end of the solution, the state
         variable was reduced to about 100,000 feet.  However, using
         only REAL variables would have been inaccurate and using only
         DOUBLE  PRECISION was a waste of CPU time.

(b)   At one point, the value within a variable for the number of days
        since 1910 exceeded 32767 when the Y2K situation was also close
        to becoming a problem.  However, the total number of days never
        exceeded 65535, so a 4 byte integer was never required.  BUT,
        the FORTRAN flavour which was being used did not support
        UNSIGNED  variables.  The only occasion when that became a
        problem was when the number of days had to be divided by 7
        in order to determine the day of the week.  Since that FORTRAN
        compiler thought the variable was SIGNED, before dividing by 7
        the  "SXT   R0"  instruction extended the high order bit in R1 
into R0
        just prior to the  "DIV  #7,R0"  instruction.  Rather than some very
        complicated manner of managing that single situation, the best 
solution
        seemed to be to change the  "SXT  R0"  instruction to the  "CLR  R0"
        instruction - which, in effect, changed the variable being used 
during
        the divide operation to UNSIGNED from SIGNED.  If that
        FORTRAN compiler had also supported UNSIGNED variables,
        the same sort of solution as was used in (a) might have been used.
        It was recognized that making such a change to the program being
        executed would force future updates through the same requirement,
        however, there were very few  "SXT  R0" being used and only ONE
        which was followed by the  "DIV  #7,R0"  instruction.

Probably the same sort of method could also be used with C when such
situations occur.  In general, although it might be considered a subversion,
a more appropriate point of view might be that the same data requires a
different protocol in the algorithm that is being used.

Jerome Fine