User talk:Dinosaur

From Rosetta Code

Fortran[edit]

Dear Dinosaur, you contribute a lot to Fortran code on Rosetta and that is great, and I appreciate it because your wide and deep experience in Fortran is indisputable and your contribution currently is a significant part of progress for solved tasks in Fortran! The only remark: I noticed that you are using often old F77 standard, so in order not to confuse the new and naïve audience about the possibilities of modern Fortran, would you be so kind to specify always the standard you are currently using in the code? Thank you! Zmi007 (talk)

Ah, I had of course regarded it as obvious what flavours of furrytran were in the code. More modern compilers continue to accept F77 as well as make available new features and even, new conveniences, such as the PARAMETER statement, generic function names and interesting functions/statement features such as ALL, ANY, COUNT, and, above all, array assignment syntax. For larger programmes, the MODULE protocol is a great relief compared to massive COMMON statements - at the Culham Science Centre I encountered a 80,000 line prog. that had about a hundred subroutines, all of which included a file containing a COMMON statement of twenty lines or so, and deep within that appeared variables I,J. No wonder my debugging stuff behaved as oddly as the programme. Fortunately, I had my own furrytran editor (written in furrytran) that distinguished between source text, text literal content and commentary text, and, knew about continuation lines. And, by default did not perform literal text matching so an assault on "I" did not damage "IF" and so forth. On the other hand, I dislike the flabbily verbose drivel associated with "KIND" in the latter furrytrans, especially as they increase the obscurity. REAL*8 seems both succint and clear enough to me. And the generality is specious, as decimal computers were once common but these days, everyone seems to regard intel as universal.
I tend to stick to F77 style (aside from these tasty new features) because I have had some odd experiences with latter-day compilers, such as spaces becoming important (so MODULE BIG BAG lead to odd and troublesome behaviour that vanished with MODULE BIGBAG) and a startling encounter with tabs and the old-style 72-character limit. It appeared that tabs were replaced by spaces, and suddenly, source following such tabs was pushed beyond character 72 in the expanded interpretation. I usually make some remark about "older" fortrans, but I test the progs. with a F95 (as I recall, I'm in a cybercafe, not near the compiler) style compiler. I shall endeavour to be more explicit...
For instance (having just now looked again at "Compare a list of strings" I see you missed the remark "Later Fortran offers the special function ALL...", and the use of this sort of function is available only with F90 and later. Thus, the example code will not compile with F77, only with F90 and later. And, I declare and use an array of character variables; this is not a "hack" but an ordinary array of thingies, each thingy being almost a string, lacking only a current length.
I really enjoy what you are writing here and hope you don't take personally my remarks. Feel free to correct anything I wrote there. ) Zmi007 (talk)
No worries. I'm glad to see that someone is interested in what I have had a go at. I find the Rosettacode webpage/wiki organisation a bit difficult to follow - I found a list of tasks not implemented in Fortran, then for ages couldn't find that again (not recalling what wanderings had led me to it) but when I found it again a few days back, this time I remembered to save a bookmark. Which hopefully, won't vanish after a crash or whatnot. Otherwise, I might stumble upon a possible task without Furrytran, and if it tweaks my interest I'll have a go. I still haven't rediscovered the web page showing statistics such as how many tasks each language has an entry for. Meanwhile, I'm back in a cybercafe, but I checked, and the compiler I use notes Fortran 90/95.

Hexapawn[edit]

Thanks for the memories. I found back this year in my attic a set of matchboxes with bears and I didn’t remember for what purpose it was. You give me the answer. I am a younger dinosaur I began to program Hexapawn in 1974 with an IBM 360/30 with 32KB of storage and Fortran IV. Good old times. --PatGarrett (talk) 15 :54, 8 May 2016 (UTC)

You're welcome! Despite our family's many moves I also have a batch of old matchboxes with diagrams stuck on the top, but the smarties (or M&M) are long since eaten. I recall prowling the railway station at Manor Park to find fresh and firm matchboxes not badly stained by rust (from iron particles cast off from the train's brakes) - after a few soakings by rain the cardboard became too floppy and by then I had become a connoisseur of "Beehive" matchbox quality.

Cheap Fortran[edit]

Hello. While writing on Zmi007's talk page, I couldn't help but see your previous comment that "I don't have access to a F2003 compiler, and don't want to spend my money to gain access, especially when the prices I've seen are around US$3,000."

You may be interested to know that there are much cheaper compilers: Intel, PGI and Absoft are all less that $700 (at least single user licenses on Windows or Linux). Lahey Fortran has a cheaper version, and a slightly more expensive one ($850).

But I would recommend the free and open source GNU Fortran. Its conformance to F2003 and F2008 is getting better and better.

Also, some vendors are releasing a free version, usually for personal use, and usually for Linux. At least Intel, Pathscale, Oracle and (recently) PGI do that. Even if you use primarily Windows, you may get a Linux distro in VirtualBox to make tests on these compilers. It's interesting at least to see how a program will behave with another compiler.

I have once seen a free beta version of IBM XLF for MacOSX on PowerPC, but it was 10 years ago (when Apple had some success for HPC with its high-end PowerMacs), and it's not free anymore, and anyway Apple has switched to Intel processors.

If you have access to ACM publications, there is a document on conformance of compilers, released 3 or 4 times a year (ACM SIGPLAN Fortran Forum). The information is also available on Fortran Wiki (F2003, F2008).

Arbautjc (talk) 19:08, 24 November 2016 (UTC)

Thanks! I have a dual-boot system with Linux Mint, but I don't use Linux enough to be familiar with its rituals, thus although I have looked at fortran compilers for Linux and have downloaded (via a cybercafe) I have not carried this forward into an installed compiler even though I do want a code file for each of wunduhs, Linux and Mac for the large project I am maintaining. But because it is largeish (40,000 lines or so, counting difficult thanks to libraries) there are compatibility details that likely arise and I haven't flogged myself into anything beyond a superficial inspection and discouragement. The last time I tried more seriously (at work, the installation disc for Compaq fortran was misplaced) I found that an Intel compiler (a plague to install) ran much slower, as did its code (at least in my tests, and without digging into compiler parameters) and the then Lahey compiler (an evaluation version and easy to install) fussed over some syntax facilities, being strict about THIS%THAT instead of allowing THIS.THAT among others, though again there may have been compiler options. Both these were expensive compilers, though my employer could easily afford them. Then, the installation disc was rediscovered (it had been put somewhere safe, by me...) and the impetus vanished in the face of more immediate development wishes and other activity. Somewhat later, I tried a free Mac fortran compiler, that also worried over THIS.THAT. In principle, all this could be handled, but at a cost in time an patience when other activities beckon.
I gather the GNU Fortran compiler is a part of the project to write a compiler for every possible language, via translation to a form of C then compiling that, rather than devising a native compiler for each case. This is interesting in its own right, but I have a nit to pick as I use the arithmetic-IF in the Binary Search algorithm and in a few other cases where a three-way-IF test is needed, and C doesn't allow for that construction. So, I'm mumbling already.
I peeked at the F2003 status schedule, and see a lot of terse stuff that would require further study to appreciate, thus a bare "Length of names and statements" lacks obvious interpretation. But I notice mention of "recursive I/O" as one limitation I have often been troubled by. On the other hand, I don't recognise mention of some of the subtle issues that can arise, one of which was ... an allocatable array (declared locally) is passed to a subroutine, which determines the size needed and allocates it; on return the array continues to exist in the caller's context but is now alloacted storage. The Compaq compiler handled this (it was to allocate a correctly-sized array to represent a large sparse array, the analysis for this being done in the called subroutine) but the Intel compiler (I think) did not. Perhaps this would come under the phrase "Transferring an allocation"? Perhaps something else. A great deal of time can vanish in this sort of thing. Dinosaur (talk) 08:07, 25 November 2016 (UTC)
No, GNU Fortran is a native compiler (it has nothing to do with, for instance, f2c). As a side note, even f2c should be able to do an arithmetic if (it's easy to emulate in C with 'if' and 'goto'). However, GNU Fortran won't accept the X.Y notation, unless maybe with an option. But it is accepted by Intel Fortran and Absoft Pro Fortran.
Length of name: they are now limited to 63 characters by the standard. I suspect many implementation already allow more. Length of statement: limited to 255 continuations lines.

Regarding allocation transfer, yes, that's a possible use of the MOVE_ALLOC intrinsic. Notice that now the standard allows to pass an allocatable array as parameter. It may be allocated or unallocated upon entry of the subprogram. Even a function result may be allocatable. There is also a very useful feature: an assignment to an array will automatically allocate it to the correct size. I suggest you have a look at the standard or a good recent book on Fortran (some authors that come to mind: Metcalf, Chivers, Brainerd). The standards F2003 and F2008 may be found for $60 on the ANSI web site, or very close drafts are available at J3: in several subfolders of this one (each represent a publication year), the "007" documents refer to the standard. For instance, the latest draft of the upcoming Fortran 2015 is 16/16-007r2.pdf. The standard is the most complete reference, but it's sometimes not very easy to follow.

More generally, I would suggest that whenever possible, you use standard Fortran unless of compiler extensions, especially when there is a simple equivalent standard feature. Of course, this could mean updating your program, but it would add much to portability. However, not all compilers follow fully the 2008 or even the 2003 standard, but they tend to be updated, more or less slowly. Intel is close to finish the Fortran 2003 conformance, but for instance the Absoft compiler is still quite far from it, and this may lead to some bugs. For instance, real(Z'...') has a meaning in Fortran 2003, and another meaning as an extension in Absoft (it was not allowed by the Fortran 95 standard). Allocation on assignment is not supported either, yet.

To learn more on new features in F2003, have also a look at this and this.

Arbautjc (talk) 21:22, 25 November 2016 (UTC)

Sorting algorithms/Insertion sort[edit]

Please don't remove the "incorrect" template. It's important so that the task appear here: Category:Fortran examples needing attention. And it's easy enough to write a correct insertion sort, it's absolutely not enough to leave it as is and hope it won't crash. Either correct it, and then remove the template, or leave it so that someone can see it and make the proper modifications.

Eoraptor (talk) 15:33, 29 December 2017 (UTC)

So, could you have one to provided suitable modifications? I imagine that the originator did test runs on their system, and all went without surprise. I suspect that many other compilers will produce working code too, so anyone copying this source code would likely gain success as well. It is likely that there will be textbooks showing this code without warning, so, I thought introducing a warning to the source file sufficient, as it is followed by an older-style version with the compound test broken into the formal equivalent (and thus wastefully testing J the first time) for an example. Anyone implementing an insertion sort should check its working on their system, even though one might expect published algorithms, correctly transcribed, would work correctly. Alas, given the unreliable vagueness of the language specification on this question, seemingly minor changes to the code may result in changed behaviour! So indeed, the code should be such as not to succumb to this vagueness, and documenting the risk might be regarded as insufficient.
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. 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. 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) 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, 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 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? 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. Eoraptor (talk) 13:43, 31 December 2017 (UTC)