User talk:Dinosaur: Difference between revisions
m
→Sorting algorithms/Insertion sort
(→Sorting algorithms/Insertion sort: Righto, I've re-twiddle the code.) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
Line 55:
:The twiddled version is not actually a formal equivalent of the commented-out DO WHILE loop, nor need it be. I've left the "incorrect" template in for your possible removal, as my judgement may not be to your taste. Cheers, and happy New Year. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 02:03, 30 December 2017 (UTC)
::That a test "goes without surprise" does not make a program correct either. You seem to have a problem to admit that an incorrect program is incorrect. Never mind. An insertion sort is not hard, if you don't know how to do it, I will now. [[User:Eoraptor|Eoraptor]] ([[User talk:Eoraptor|talk]]) 19:51, 30 December 2017 (UTC)
:::Done. I removed what you wrote about the wrong task, I'll let you make the additions you deem fit. By the way, in my opinion, you are making Fortran sections too verbose, and you are making it look older than it is. "Old Fortran" is one thing, that belongs to history (and this is indeed interesting, as ''history''), modern Fortran is another, and mixing both looks weird. However, as there doesn't seem to be any "standard" about contributions on Rosetta Code, it's really up to you. My suggestion would be to put all such historical notes in a "Old Fortran" subsection (or any name that will clearly identify the section as related to long-gone compilers and machines) [[User:Eoraptor|Eoraptor]] ([[User talk:Eoraptor|talk]]) 20:01, 30 December 2017 (UTC)
::A while ago I helped a fellow with a weird and unexplained programme that turned out to be a numerical simulation of an artillery gun firing a shell (recoil, etc. in sub-millisecond steps), written in a hybrid of special simulation language phrases mixed with plain Fortran source that would be fed to a processor that would spit out ordinary Fortran source, that would be compiled and run. I get the same feeling when looking at the variants written in the many rather different languages: no explanation of what something does - is it a built-in facility/notation, a standard library item, a feature from a popular extension library, ''etc''. With no indication of the plan of attack, nor what guided various choices, one is adrift in a fog. Though I have also had similar experiences looking at old code... The InsertionSort method admits of many tiny variations in usage, often involving dodging or introducing wasted actions. The version you introduced for example involves a wasted test on J, required because the strictures of structured programming make it difficult to avoid, especially since Fortran does not offer a ''repeat ... until test'' construction that would avoid an un-needed initial test in that formulation of the method. Which is why I left the compound expression in (but commented out), for matching with with the example code at the head of the article, rather than introducing a non-matching form. Someone might read that and conclude that the compound form, as in the example, is so much better...
::The example code at the head of the article relies on short-circuit evaluation without mention (even though the Wikipaedia article does warn on this) and many of the examples in the various languages also appear to rely on partial evaluation too, without remark, matching the example code, or not matching it, without remark. This may be correct, if short-circuit evaluation is the style for that language, or it may be incorrect. The correctness you praise then relies on the unmentioned details of a particular language, unknown to non-users of the language, and probably not in the front of the consciousness of the author either. Put another way, the same algorithm would succeed or fail in various languages, depending not on the source code, but on the choice of a recondite detail of the language's implementation that may or may not be specified in one standard or another that a particular compiler/interpreter/programmer may or may not follow. The original author did after all test their version and found that it worked. There are innumerable programmes that have worked when checked, and worked throughout their use (apparently), and when transferred to a different compiler, fail. I suppose there is "correct" (the damn thing works) and "Correct", the latter being so for code that will work for all variants of a compiler - correct compilers only, of course. But for complex programmes, "Correct" is a numinous state and unattainable, since over time the language standard is revised to mention newly-discovered ambiguities, or, change their interpretation. As a historical example, the DO-loop interpretation in early Fortran always executed at least once, since the test was made at the end of the loop - and in those days there was no separate standard as such, what the specific compiler did ruled. For most loops this saved a test, and sometimes it was desired behaviour in certain situations (such as this one!) though not in others, and the latter choice became the approved way. Without change to the code, a correct prog. becomes incorrect through change to an entirely separate item. Unfair!
::But yes, I'll admit that I think that short-circuit evaluation is correct, and that code that works with that is correct (especially when it is tested and works correctly), and that the order of evaluation of expressions is fully defined (tie-breaker rule: left-to-right for equal precedence), and I resist the more recent Fortran specifications whereby, maddeningly, it is specified that this is not specified. Because I think that is incorrect... Time for a drink. Cheers, [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 02:26, 31 December 2017 (UTC)
:::There is already a task about '''[[Short-circuit evaluation]]'''. You are free to read it, or not, but do not claim you are left alone in a fog. Anyway, the standard has not changed much since the 1978 flavor: "It is not necessary for a processor to evaluate all of the operands of an expression if the value of the expression can be determined otherwise." (Fortran 77, section 6-20). It is permitted, but not mandatory, hence you can't count on it. Anyway, the order of evaluation is not guaranteed either. A program that relies on short-circuit evaluation is not standard conformant, and it has never been. A compiler may provide such a feature ''and document it'', but I know no example. Have a look at [https://gcc.gnu.org/ml/fortran/2007-03/msg00368.html this] for gfortran, for instance. Now, you are free to write buggy code which happens to work sometimes, you may even be proud of it. Who cares? [[User:Eoraptor|Eoraptor]] ([[User talk:Eoraptor|talk]]) 13:37, 31 December 2017 (UTC)
::::And I suppose it's not worth mentionning that syntax like "INTEGER*1" is not standard conformant either (and has never been). There are probably other nonstandard "features" you are proud to (ab)use. [[User:Eoraptor|Eoraptor]] ([[User talk:Eoraptor|talk]]) 13:43, 31 December 2017 (UTC)
| |||