Parametric polymorphism: Difference between revisions
→{{header|Fortran}}: Polymorphic arithmetic. Beware.
(→{{header|Fortran}}: Polymorphic arithmetic. Beware.) |
|||
Line 458:
There would be a function (with a unique name) for each of the contemplated variations in parameter types, and when the compiler reached an invocation of FIND(...) it would select by matching amongst the combinations that had been defined in the routines named in the INTERFACE statement. The various actual functions could have different code, and in this case, only the <code>INTEGER*4 THIS,NUMB(1:*)</code> need be changed, say to <code>REAL*4 THIS,NUMB(1:*)</code> for FINDF4, which is why both variables are named in the one statement. However, for searching CHARACTER arrays, because the character comparison operations differ from those for numbers (and, no three-way IF-test either), additional changes are required. Thus, function FIND would appear to be a polymorphic function that accepts and returns a variety of types, but it is not, and indeed, there is actually no function called FIND anywhere in the compiled code.
That said, some systems had polymorphic variables, such as the B6700 whereby integers were represented as floating-point numbers and so exactly the same function could be presented with an integer or a floating-point variable (provided the compiler didn't check for parameter type matching - but this was routine) and it would work - so long as no divisions were involved since addition, subtraction, and multiplication are the same for both, but integer division discards any remainders. More recent computers following the Intel 8087 floating-point processor and similar add novel states to the scheme for floating-point arithmetic: not just zero but "Infinity" and "Not a Number", which last violates even more of the axia of mathematics in that ''NaN'' does not equal ''NaN''. In turn, this forces a modicum of polymorphism into the language so as to contend with the additional features: special functions such as IsNaN(x).
More generally, using the same code for different types of variable can be problematical. A scheme that works in single precision may not work in double precision (or ''vice-versa'') or may not give corresponding levels of accuracy, or not converge at all, ''etc.'' While F90 also standardised special functions that give information about the precision of variables and the like, and in principle, a method could be coded that, guided by such information, would work for different precisions, this sort of scheme is beset by all manner of difficulties in problems more complex than the simple examples of text books.
Polymorphism just exacerbates the difficulties, thus, on page 219 of ''16-Bit Modern Microcomputers'' by G. M. Corsline appears the remark "At least some of the generalized numerical solutions to common mathematical procedures have coding that is so involved and tricky in order to take care of all possible roundoff contingencies that they have been termed 'pornographic algorithms'.". And "Mathematical software is easy for the uninitiated to write but notoriously hard for the expert. This paradox exists because the beginner is satisfied if his code usually works in his own machine while the expert attempts, against overwhelming obstacles, to produce programs that always work on a large number of computers. The problem is that while standard formulas of mathematics are fairly easy to translate into FORTRAN they often are subject to instabilities due to roundoff error." - John Palmer, 1980, Intel Corporation.
But sometimes it is not so troublesome, as in [[Pathological_floating_point_problems#The_Chaotic_Bank_Society]] whereby the special EPSILON(x) function that reports on the precision of a nominated variable of type ''x'' is used to determine the point beyond which further calculation (in that precision, for that formula) will make no difference.
Having flexible facilities available my lead one astray. Consider the following data aggregate, as became available with F90: <lang Fortran> TYPE STUFF
| |||