User talk:Dinosaur: Difference between revisions
→Cheap Fortran: But also, a cost in time and patience before payoff pleasure.
(→Cheap Fortran: new section) |
(→Cheap Fortran: But also, a cost in time and patience before payoff pleasure.) |
||
Line 31:
[[User:Arbautjc|Arbautjc]] ([[User talk: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. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 08:07, 25 November 2016 (UTC)
| |||