>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

Reply via email to