Programming language failings [was Re: strangest systems I've sent email from]
Jerome H. Fine
jhfinedp3k at compsys.to
Mon May 9 22:41:05 CDT 2016
>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
More information about the cctalk
mailing list