I use the f0.x descriptor in format statements a lot, and find it very useful. However if the real number that is being output is < 1.0 then the leading zero is omitted i.e.if 0.333 is output as f0.3 then you get .333. I don't think any scientist would omit the leading zero and it certainly looks ugly. It would improve matters if was included. (Or am I missing something?)
There was no compiler option or language syntax to do this when I last looked at this. read https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/536887
If you really need that you would be best writing your own output function.
program LeadingZero implicit none character(len=6) :: field write(field,'(f0.3)') 0.123 if(field(1:1) == '.') field = '0' // field if(field(1:2) == '-.') field = '-0.' // field(3:) print *, field !============ write(field,'(f0.3)') -0.123 if(field(1:1) == '.') field = '0' // field if(field(1:2) == '-.') field = '-0.' // field(3:) print *, field !============ write(field,'(f0.3)') 0.0 if(field(1:1) == '.') field = '0' // field if(field(1:2) == '-.') field = '-0.' // field(3:) print *, field end program LeadingZero 0.123 -0.123 0.000
To expand on Jims code create a function like:
module fred implicit none contains function vstrlz(flt,gfmt) result(gbuf) character(len=:), allocatable :: gbuf real, intent(in) :: flt character(len=*), optional, intent(in) :: gfmt character(len=40) :: gtmp integer :: istat gtmp = '' if(present(gfmt) ) then ! specified format write(gtmp, gfmt, iostat=istat ) flt else ! generic format write(gtmp, '(g0)', iostat=istat) flt endif if( istat /= 0 ) then gbuf='****' return endif if ( gtmp(1:1) == '.' ) then gbuf = '0'//trim(gtmp) elseif(gtmp(1:2) == '-.' ) then gbuf = '-0.'//trim(gtmp(3:)) elseif(gtmp(1:2) == '+.' ) then ! S format adds a + gbuf = '+0.'//trim(gtmp(3:)) else gbuf = gtmp endif end function vstrlz end module fred program testy use fred, only: vstrlz implicit none print *, vstrlz(0.123,'(f0.3)') print *, vstrlz(-0.123,'(f0.3)') print *, vstrlz(0.123,'(spf0.3)') print *, vstrlz(0.123) pause ! ******output below**** ! 0.123 ! -0.123 ! +0.123 ! 0.1230000 ! Fortran Pause - Enter command<CR> or <CR> to continue. end program testy
Much better Andrew. Nice catch on the '+.'.
Question for you and/or Steve on your function.
result(gbuf) is specified as allocatable, nothing inherently wrong with this... (and this provides for a functional trim)
now then, in the use of the function in your program the result is directly use in print * statement. IOW the result is an expression temporary.
My question is, does, and at what point, the temporary allocatable get deallocated?
(not deallocated, deallocated at end of statement, deallocated at end of program/subroutine/function)
.AND. is the descriptor for the allocatable located on stack or SAVE?
Thanks everyone; I have done something like this in the past but it is a laborious solution to a simple problem, and what happens when you need to output 10 such fields in a line?
The main thrust of my comment is that Fortran prides itself on being the scientific programming language; no scientist would write .333 without the leading zero, so why can't the f0.x descriptor?
The Fortran standard says that it is implementation-dependent whether there is a leading zero in F format for values less than 1. The Intel Fortran (and DEC/Compaq before it) behavior is to omit the zero. Some other Fortran compilers insert the zero. I have seen requests for an option to supply the zero, but it has not yet been implemented.
To Jim's question, the allocatable function result is deallocated at the completion of the statement that references the function. The descriptor is wherever the compiler chooses to put such things - probably static for a non-recursive procedure.
Chris G. wrote:
Could it be implemented as a compiler option?
It isn't a new issue and clearly isn't that important to most people if it was it would be "fixed". Don't expect Intel to change it any time in the next decade, they have plenty of stuff to keep them busy.
If it is a big deal then some helper functions like I posted earlier will solve it without too much difficulty. With a big program it is usually not good design to have large numbers of write statements all over the place. Using a small number of utility routines makes more sense, it then becomes easier to manage change when you want the output to go to different things in different ways e.g. pipes/files/consoles/ascii/Unicode/dialogs etc etc
It could be a compiler option - there are already several that modify formatting behavior. I'm not sure how many flag bits the compiler has left for this purpose. When I was on the compiler team, I'd see a request for this maybe once every two years. It seems like a small thing, but there is a cost to any change and it would add complexity to an already complex function.
That said, I have a strong dislike for options that change behavior and would rather see such things expressed in the source. Too bad that the standard didn't add something like the SP/SS formats to control this behavior, but the subject hasn't come up while I've been on the committee, and I don't see the other members being too interested in it.
This feature should be available.
Many countries use the metric system. Under this, it is mandatory that numbers < 1 have the 0 prefix.
So it is more than a nice to have option.
I must say that I'm disappointed. I have a client who insists that the leading zero is present for numbers between 1 and -1, and I find it absurd that a scientific programming language can't easily do this. Fo me this is a major issue.
I am ambivalent on this one, but there is some discussion of this in the following link, and I would agree it is a flaw in the fortran standard to not have some specific syntax to include or exclude an leading zero before the decimal point.
To the OP, what is the scope of the problem? is it 10s, 100s, 1000s of lines of code with write statements that are affected? Writing your own code top fix it like post #3 is a few hours work at most if it is a few hundred lines of code. Is the data written to files? If so you could also make a file parser to replace " .d" ( space dot [0-9] ) with "0.d" that would be a small task also.
Even if this "defect" was given high priority an Intel (which is unlikely) a solution in an ifort release would be months away so if your problem is immediate you must find another solution, either to write additional code or use a different compiler, though that latter solution might be fraught with other issues dependant on how standrad your code is..
I believe the behavior of the missing 0 for '0.nnnn' printed values has more to do with punch cards and fixed field width printouts. IOW a more precise number can be conveyed. With reference to Andrew_4619's link, machine reading is not susceptible to not seeing the leading "." on such numbers. Also, on columnar printouts, a number with a leading "." is jiggered over one column so it is visually apparent.
This said, with all the recent effort to modernize Fortran, it would be nice to have a formatting descriptor that is more modern such that not only a single leading 0, but also additional editing features (commas, or period formats, zero filled, etc...).
Commas or periods as an option are already in the standard, both as an OPEN specifier (DECIMAL=) and as format items (DP, DC). Zero fill for integers is also there (Iw.m, etc.). Something along the lines of SS/SP/S would be the best option. Suggestions for edit descriptor spelling?
Though I generate very complex printouts using Fortran, I have always used Fx.y with x>y+2 or x>y+3.
For example, in printing chemical molar compositions, whose values are always between 0 and 1, the standard format used if F8.6.
It is very difficult for me to understand the use of F0.x.
Luigi R. wrote:
It is very difficult for me to understand the use of F0.x.
Field widths of 0 typically signify that you leave it to the compiler to pick a suitable value of the field width to display fully the number(s) that you ask to be written out.
Chris G. wrote:
.. The main thrust of my comment is that Fortran prides itself on being the scientific programming language; no scientist would write .333 without the leading zero, so why can't the f0.x descriptor?
See this recent thread at comp.lang.fortran forum where you will find a couple more coders with similar interest in forcing the leading zero: https://groups.google.com/d/msg/comp.lang.fortran/p357wX8KRnY/V2ZQ24RbBAAJ.
I wholly support your position. It's a no-brainer as far as I'm concerned: Fortran standard itself should include a facility for coders to include the leading zero and those working on the Fortran 202X standard revision (https://wg5-fortran.org/f202x.html) should promptly include such a feature. But that could be fourscore years away; the committee has until 2029 before they would need to "vote" on yet another name change! So in the meantime, Intel Fortran should include a compiler option for the same. And for both, it should be a simple work item to include this without much effort. But if it's not, that it's presented as a 'great deal of effort', then it is only a sad reflection on their work process and/or system that it be so.
It should not be incumbent upon you to forgo your need for a programming language to work for you and help you make your computing instructions convenient and efficient, especially on such a simple matter that's effectively an oversight considering all that has been included in the data edit descriptors.
I suggest you submit a support request at the Intel Support Center (OSC) for this: https://supporttickets.intel.com/?lang=en-US