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

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