Parametric polymorphism: Difference between revisions
→{{header|Fortran}}
Line 461:
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, 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
INTEGER CODE !A key number.
CHARACTER*6 NAME !Associated data.
INTEGER THIS !etc.
END TYPE STUFF
TYPE(STUFF) TABLE(600) !An array of such entries. </lang>
Suppose the array was in sorted order by each entry's value of CODE so that TABLE(1).CODE <= TABLE(2).CODE, etc. and one wished to find the index of an entry with a specific value, ''x'', of CODE. It is pleasing to be able to write <code>FIND(x,TABLE.CODE,N)</code> and have it accepted by the compiler. Rather less pleasing is that it runs very slowly.
This is because consecutive elements in an array are expected to occupy consecutive locations in storage, but the CODE elements do not, being separated by the other elements of the aggregate. So, the compiler generates code to copy the required elements to a work area, presents that as the actual parameter, and copies from the work area back on return from the function, thereby vitiating the speed advantages of the binary search. This is why the <code>INTENT(IN)</code> might help in such situations, as will writing <code>FIND(x,TABLE(1:N).CODE,N)</code> should N be often less than the full size of the table. But really, in-line code for each such usage is the only answer, despite the lack of a pre-processor to generate it.
Other options are to remain with the older-style of Fortran, with separately-defined arrays having a naming convention such as TABLECODE(600), TABLENAME(600), ''etc''. thus not gaining the unity of declaring a TYPE, or, declaring the size within the type as in <code>INTEGER CODE(600)</code> except that this means that the size is a part of the type and different-sized tables would require different types, or, perhaps the compiler will handle this problem by passing a "stride" value for every array dimension so that subroutines and functions can index such parameters properly - at the cost of yet more overhead for parameter passing, and more complex indexing calculations.
In short, the available polymorphism whereby a parameter can be a normal array, or, an array-like "selection" of a component from an array of compound entities enables appealing syntax, but disasterous performance.
=={{header|Go}}==
| |||