I have a configuration file that defines templates, options, tokens ete etc to allow a user to format data from my software for a vast range of different CNC type machine controllers…
Often leading spaces on real numbers are nice because is collimates data and makes it more human readable. In other cases this pumps up the files size or the target hardware does not like it so leading spaces are omitted. In the first case something might be output in a user supplied format ‘(F10.3)’ and the latter case ‘(F0.3)’.
There is a special case if the real is between 0 and +1 as ifort would give the values ‘.123’ rather then ‘0.123’. It just so happens on Friday a customer was using a new controller that didn't like a numbers starting with a decimal point in some cases and it also needed no leading spaces, i.e. I need that leading ‘0’.
I gather from reading that the Fortran standards leaves that leading ‘0’ down to the choice of the compiler vendor.
The question is, is there any option (I have looked and failed to find one) that could force the leading zero perhaps analogous to the “SP” format descriptor/flag that forces a leading ’+’?
I can solve the by using an F format e.g. F10.3 where the field width is over-wide as this (in Ifort) adds spaces and a leading zero. Then I would run this through a function to strip the leading spaces out. This required the addition of another ‘flag’ in the user configuration and a software update and release whereas any format based change requires just and edit to an external configuration file….
Any ideas anyone?
A Google search on this topic reveals that others have also attempted this. The solutions are not elegant, but it may be possible to do with a few lines of code, so you may get away with a simpler solution than requiring changes to your configuration file.
Thanks for looking David, solving with some code is no big deal, it is just the up issue and version release is a pain for such a small thing. And change in the format would not have involved any code change as he format statements are externally defined in user data files.
@Steve. That would be an oversight in the Fortran standard having the leading zero as being vendor dependant? It does rather means that the output of a standard conforming program is vendor dependant does it not? You would have though the retrospective 'fix' would be a format item in the style of S/SP/SS that forces a behaviour?
app4619 wrote:There is no evidence of this being an oversight. In fact, the standard says deliberately that the leading zero is "optional", although the last quoted sentence is a bit oddly worded ("optional".."shall").
That would be an oversight in the Fortran standard having the leading zero as being vendor-dependent? It does rather means that the output of a standard conforming program is vendor-dependent does it not?
For an internal value that is neither an IEEE infinity nor a NaN, the output field consists of blanks, if necessary, followed by a minus sign if the internal value is negative, or an optional plus sign otherwise, followed by a string of digits that contains a decimal symbol and represents the magnitude of the internal value, as modified by the established scale factor and rounded to d fractional digits. Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one. The optional zero shall appear if there would otherwise be no digits in the output field.
Apart from what the standard stipulates, it would be nice to have the compiler produce the optional 0 when the programmer desires it. You have written about the formatting requirements of controller input. Another situation is where one wishes to compare the outputs from more than one Fortran compiler with a file-compare utility. The optional 0 characters would result in false "different" flags. Likewise, whether the prefixes 'E' and 'D' (used in output exponent fields) are lower or upper case varies from compiler to compiler. Some compilers permit the user to choose the case of the E/D by setting a run-time environment variable.
That says it is arbitrarily in one of two different states and the F2003 standard is thus clarifying the fact that they had failed to standardise at some earlier point in time.....
That failure should be viewed in this light: the first Fortran standard was born in the 1960s, but did not carry much weight with vendors at the time. Thus, we had IBM Fortran, CDC Fortran, PDP-11 Fortran, etc., and programs were often not portable from one machine to another.
Given Fortran's emphasis on backward compatibility and a time constant larger than 1 decade, there is a considerable barrier to changing something that was "optional" to "required" or "user-selectable".
>>By the way my first FORTRAN experiences were on a CDC Cyber 170/855 using a teletype terminal!
Mine was DEC FORTRAN-D and FORTRAN-II with Teletype terminal (KSR model with 10cps paper tape).
I have to say that virtually everyone I knew that learned how to program on a 10cps (characters per second (110bps)) teletype, with a language such as FORTRAN-II that took 3 passes of the paper tape to produce an intermediary output tape, that is then fed into an assembler (SABER Assembler), and then the output of that (binary file), is then loaded in via a binary loader (5 passes of paper tape at 10cps), that these programmers tended to NOT make mistakes. (Or they quit programming at took business classes.)
The only negative side is this type of programmer also uses the minimum number of letters in variable names and omit most comments.
I think it would be a good learning experience for CS courses to expose the students to this type of programming environment (simulated of course).
I used to have 72/80 column fortran writing pads and everything got written in pencil by hand first... Any coding notes were in the pencil version only.
But yes getting it wrong was a killer and would result in being buried in yards of paper. Damn those core dumps.....
Just to give 5 cent - it's horrible to see how less real computer knowledge will be mediated to computer science students today. They think computer has unlimited memory (as Turing maschine) and programm (in)efficiency is a just bad joke because compuer will be get quicker before projects will be ready.
My first computer has tape drive, but the file OS code was printed hexadecimal on a paper and must be given in via terminal. There was one print error, just realised after some days to get it worked. So before the whole thing could be used, the hexadecimal code must be converted back to assembler code, identify the bogus instruction, replace with correct instruction, convert back to hexadecimal and put in again - now I has my first file OS, can load basic interpreter and do some programming. Oh, no internet of course.
Will be interesting to simulate that situation in computer room again 🙂
One other point for reminiscing is at my first professional job after college was with Digital Equipment Corporation as a software support engineer on PDP-8I and PDP-8E systems. As a software support engineer we did not have a computer terminal in our office and we seldom directly used a computer at all. Similar to app4619's experience we typically used printouts, in my case a few 6" thick stacks, that we would hand edit to make revisions and additions. We would flag the edge of the pages with changes with colored tape. We would then send the printouts, together with our magnetic tapes via office courier to the computer service center which would then load the tapes, edit the files, then submit the programs for batch compiling. Typical turnaround was a day. You would request if you needed new listings and or paper tape binaries. In the early days, the PDP-8I (PDP8-I) programs were cross compiled on a PDP-10 and even emulated on the PDP-10. Occasionally (in first year) we would get computer time on a physical machine when emulation could not resolve a programming problem.
We have it easy now except for the *&^%!%% auto-generated documents. Ever since about the mid 1990's programing reference manuals have been getting worse IMHO.