User talk:Zmi007: Difference between revisions
→Writing an integer
Line 36:
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. The system I use dual starts to Linux or wunduhs, so there is a possibility there, but also a lot of time and patience needed to find a compatible compiler. I do have a wunduhs F95 compiler (alas, its microflaccid "visual" interface won't work on 64 bit or later than wunduhs XP) ... And here is a collection of IFMT(n) functions...
: Seriously? ) GNU gfortran is very close to be named a F2003 compiler and costs zero $. Your current task can be solved in a very elegant and simple way with parametrized derived types but there is one big problem there: they are still missing in almost any Fortran compiler including gfortran ) So, yes, you have right here, I wrote [http://pastebin.com/Mw08KFAb similar routines] for integers with interface int2char but using kind parameter extends its usability to compilers with different integer kinds. Your problem is that you attempt to preserve portability of the code for very large set of compilers, but your price for it is too high, imho (subset of the Fortran language standard of the worst supported compiler in your set). With one simple step towards F2003 standard many problems become realizable with significantly less efforts and code. [[User:Zmi007|Zmi007]] ([[User talk:Zmi007|talk]]) 23:48, 16 December 2015 (UTC)
::I don't use Linux/unix much so the rigmarole of choosing and installing a compiler is an obstacle. I definitely do not want the old-style of first choosing and installing a C-compiler so as to compile the software I first desired. Still, I have made a trial attempt in the past, and was baulked by a trivial incompatibility, namely that A%B is the official style for compound data names, and I can't stand it, and have used A.B (as I had with B6700 Algol (which uses % to dignify a line comment, as does matlab, end ...), and pl/i, etc) so I was faced with either finding a compiler variant that allowed this deviationism, or, editing the source files to conform to a disliked form. That trial compiler also was not declared F2003 and may not have dealt with some of the constructions that try the diligence of those transferring from one compiler/system to another compiler/system - those would only be found via testing and compiler complaint, but the % for . complaints swamped the initial output. A serious difficulty was expected over the STRUCTURE/UNION/MAP facility (essentially, EQUIVALENCE ideas expanded to data structures) whereby disc file records could contain different types of data. This I expected trouble over but did not reach because of the .% issue. There is the TRANSFER facility that is approved furrytran these days, but I want to be sure that no actual transfer to/from work areas takes place! Data shovelling takes a lot of time, and adding intermediate stops would exacerbate the delay. To check on this would require time spent with tests and inspection of the compiler-generated code in the various cases - more time and patience. Naturally, the compiler documentation is not at all clear on such details. I was startled for instance to replace some parallel arrays by a data structure equivalent and find that the resulting programme ran about three times slower rather than at the same speed. It transpired that suddenly, a binary search routine was being invoked with its array parameter being copied in (and back), thus vitiating the speed advantage of a binary search over a linear search. Fortunately, there were only two usages, so in-line code was not too much effort and restored the pace yet retained the organisational clarity of a data aggregate in place of an aggregation of individual arrays.
:::Happy new year![[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 01:01, 31 December 2015 (UTC)
<lang Fortran>
Line 78 ⟶ 80:
END INTERFACE FFMT
</lang>
On the face of it, the task is easy, but there are traps. Many Fortran compilers do not handle the case of a WRITE statement invoking a WRITE statement as via a function (e.g. <code>WRITE (OUT,"(3A)") "Yes, we have ",IFMT(N)," Bananas!"</code>), or, possibly allow this so long as one or the other, or perhaps both refrain from using a FORMAT in them, or the statements involved do not trigger some detail. Determining exactly what is possible on one compiler is not a good idea, because another compiler may well have different rules, and thereby, portability fades. Thus the I2FMT routines play with simple arithmetic rather than unlimber the FORMAT apparatus (which is also time-consuming: a fortnight back I modified a prog. that systematically used multiple WRITE statements of assorted texts (generating .kml text for Google Earth's system) into one that used compound WRITE statements of those texts and was startled by a fivefold increase in speed of execution
<lang Fortran>
CHARACTER*10 FUNCTION SLASHDATE(DAYNUM) !This is relatively innocent.
| |||