Format descriptor F0.5

Hallo,

I observe a formatting irregularity with the print result of the first write statement

write (,'('A',F0.2)') 0.99999 write (,'('A',F0.2)') 1.00001
write (*,'('A',F0.2)') 1.99999

output: A 1.00 A2.00 A1.00

The first write statement adds an additional space between the letter 'A' and the 1.00, the other two statements print the number without a space - as wanted. This only occurs when the number gets up-rounded to 1.00000. I never observed it in any other combination. Only up-rounding to 1.000. It's also independent from the format descriptor (F0.2 or F0.6)

Regards Wolf

The inconsistency is removed by using F4.2.

Strangely the behaviour for F0.2, though apparently inconsistent, is Standard conforming in that the Standard says the result is processor dependent.

I do not know if this is a deliberate choice on the part of the compiler writer. I will pass query on to our expert for comment.

The Fortran-66 compiler for ICL 1900 series computers back in the 1970s used 0 a lot. In formats, F0.0 and I0 had a very similar behaviour to the * code available from Fortran 77 onwards (I suppose other format codes had a zero form, although I never used them). Moreover, 0 used as a statement number implied the next line, as in an arithmetic IF where one or more of the 3 choices could be the next line. I imagine, but can't recollect, that computed GOTOs also employed the same principle. (The ICL1900 Extended Fortran manual, which I still have, isn't clear on this!).

Apart from that bit of lesser-known computer archaeology, I suspect most users would expect w<d in Fw.d to exhibit some sort of odd behaviour ...

Eddie

Although the response to 'write (*,'('A',F0.2)') 0.99999 ' provides an extra space, which the others do not, this is a feature that I often would like to achieve, eg 4i0 to provide spaces between numbers.

However, I would have expected providing no space as the standard response, which is also required at most times.

While the standard may say 'the result is processor dependent', this was a frequent statement in the Fortran 77 standard, which caused so many problems for users of fortran. I am reminded of the value of kind being treated in a similar way in F90+, which causes so many problems for portability today.

John

My work around is to write to a string and check for those extra spaces. The output is input for a NC controlled machine (up to several millions of lines), the leading letters describe machine-axes. A space between the letter and the value is a syntax error. I cross-checked with G95 compiler. G95 formats F0.d correctly.

It does seem to be a bug.

The easiest workaround is to add the T2 specifier to get rid of the extra space.

write (*,'('A',T2,F0.2)') 0.99999

or use two statements

write (,'('A')',advance='no') write (,'(F0.2)') 0.99999

David.

I tried your recomendations.

T2 specifier has no influence - the space remains. Advance='no' also has no influence.

At present I write to a string and remove the extra space before I write the line to file. write (string,'('A',f0.2)') 0.9999 i = index(string,'A '); if (i > 0) string(i+1:)= string(i+2:)
write(11,'('a')') string

wolf

You're correct, the T2 method doesn't work. It only 'works' if you change it to T1. This demonstrates that there is clearly a bug in the compiler because with T1 the 'A' character should not be output.

If you want to use a string as a buffer, I would do it this way

character(len=5) string

write (string,'(F0.2)') 0.9999 write(11,'('A',A)') trim(adjustl(string))

The way you have done it writes a trailing space.

But the real issue is, this is a bug in the compiler or run time system that handles the formatting.

PS. You can tick 'Disable Smilies' to show code like 😃 instead of an emoticon.

Probably been solved already, but this example shows another way of cleaning it up: real4, dimension(3) :: value = (/ 0.99999, 1.00001, 1.99999 /) character string6, copy6 integer4 i ! do i = 1,3 write (string,'('A',F0.2)') value(i) copy = string ! take a copy if (string(2:2) == ' ') string(2:) = string(3:) write (*,'(a,'A',F0.2,a8,i6)') string, value(i), copy, ichar(copy(2:2)) end do end

My F0.5 output is much more than 3 lines, up to 8 million lines, each line has 4 F0.5. The extra space only occurs according to my observations when up rounding to 1.0000 or down-rounding to -1.0000. So it looks to me reasonable to write to a string, delete eventual spaces and print the string to file - with the hope that the bug won't survive too long. Thanks for your help, for your suggestion. Wolf

ps: I'm using F95 since version 2.0