Largest int from concatenated ints: Difference between revisions
m
→{{header|Fortran}}
(→{{header|Fortran}}: After a cup of tea...) |
|||
Line 415:
So, the plan is to regard the numbers as being text sequences aligned to the left, containing only digit characters of course - except for the fact that CHARACTER variables often end up having trailing spaces. F2003 formalised a scheme whereby such variables can be "cut-to-fit" as execution proceeds but with earlier Fortrans the standard method is to pay attention to the number of characters in use. F90 introduced a function LEN_TRIM(text) to return the index of the last non-blank character in a text so the only problem now is to decide on how long might the largest number be (and by representing numbers as text strings, there is no difficulty with the limits of INTEGER*2 or INTEGER*4 ''etc.''), and what will be the maximum number of numbers. By devising a subroutine to do the work, these issues can be handled by the caller that is providing the data. The subroutine however intends to sort the collection of texts. This could be done by damaging its parameter which might be regarded as impolite or even unwanted so instead the sort is effected via an array XLAT and juggling its values. This has the advantage that the possibly large elements of the text array are not being moved about, but means that the subroutine must be able to have an XLAT array that is "large enough". F90 standardised the ability for a routine to declare such an array at run-time; previously, arrays within a subroutine (or indeed anywhere) had to have a size fixed at compilation time. In the past this might have been handled by the caller supplying such an array as an additional parameter.
The sorting of the text array was to be by the notorious BubbleSort, taking advantage of the fact that each pass delivers the maximum value of the unsorted portion to its final position: the output could thereby be produced as the sort worked. Rather than mess about with early termination (no element being swapped) or attention to the bounds within which swapping took place, attention concentrated upon the comparison. Because of the left-alignment of the texts, a simple comparison seemed sufficient until I thought of unequal text lengths and then the following example. Suppose there are two numbers, 5, and one of 54, 55, or 56 as the other. Via normal comparisons, the 5 would always be first (because short texts are considered expanded with trailing spaces when compared against longer texts, and a space precedes every digit) however the biggest ordering is 5 54 for the first case but 56 5 for the last. This possibility is not exemplified in the specified examples. So, a more complex comparison is required. One could of course write a suitable function and consider the issue there but instead the comparison forms the compound text in the same manner as the result will be, in the two ways AB and BA, and looks to see which yields the bigger sequence. This need only be done for unequal length text pairs.
The source is F77 style, except for the declaration of XLAT(N), the use of <N> in the FORMAT statements instead of some large constant or similar, and the ability to declare an array via constants as in <code>(/"5","54"/)</code> rather than mess about declaring arrays and initialising them separately. The <code>I0</code> format to convert a number (an actual number) into a digit string aligned leftwards in a CHARACTER variable of sufficient size is also a F90 introduction, though the B6700 compiler allowed a code <code>J</code> instead. This last is to demonstrate usage of actual numbers for those unpersuaded by the argument for ambiguity that allows for texts. If the <code>I0</code> format code is unavailable then <code>I9</code> (or some suitable size) could be used, followed by <code>text = ADJUSTL(text)</code>, except that this became an intrinsic function only in F90, so perhaps you will have to write a simple alignment routine. <lang Fortran> SUBROUTINE SWAP(A,B) !Why can't the compiler supply these!
| |||