When using the “g” edit descriptor to write floating point values, I’ve found that the Intel compiler (ifort and ifx) omits the leading 0 in front of the decimal point, writing “.314” instead of “0.314”, for example. Neither gfortran or nagfor do that. Is that legitimate? I’m finding it irritating simply because without a leading numeral, JSON does not recognize the text as a floating point number.
3 Likes
I’ve run into the same issue, e.g. with the f0.3 edit descriptor, which some folks have discussed on the Intel forum: https://community.intel.com/t5/Intel-Fortran-Compiler/Leading-zeros-in-the-f0-x-format-descriptor/td-p/1175148
The Fortran standard says that it is implementation-dependent whether there is a leading zero in F format for values less than 1
I guess you could work around it by checking if your value is between 0 and 1, and then concatenating an extra "0" character before the rest of your text. Negative values could be fixed with similar logic
1 Like
Here is the text from section 13.7 of the f2023 draft.
“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.”
Here is some more text related to this.
“12.5.6.12 LEADING_ZERO= specifier in the OPEN statement
The scalar-default-char-expr shall evaluate to one of PRINT, SUPPRESS, or PROCESSOR_DEFINED. The LEADING_ZERO= specifier is permitted only for a connection for formatted input/output. It specifies the leading zero mode (13.8.5, 12.6.2.10) for this connection. It is a changeable mode (12.5.2). If this specifier is omitted in an OPEN statement that initiates a connection, the default value is PROCESSOR_DEFINED.”
You might try specifying this in an open statement to see if your compiler supports it. I think that this might also be allowed in an individual write statement. Here is the text.
“12.6.2.10 LEADING_ZERO= specifier in a data transfer statement
The scalar-default-char-expr shall evaluate to PRINT, SUPPRESS, or PROCESSOR_DEFINED. The LEADING_ZERO= specifier temporarily changes (12.5.2) the leading zero mode (13.8.5, 12.5.6.12) for the connection. If the specifier is omitted, the mode is not changed.”
If this works, then in your case it probably should be specified in the open statement so that it applies to all the valules in the file.
2 Likes
See also F2023 section 13.8.5, which begins thus:
The LZS, LZP, and LZ edit descriptors temporarily change (12.5.2) the leading zero mode (12.5.6.12, 12.6.2.10)
for the connection. The edit descriptors LZS, LZP, and LZ set the leading zero mode corresponding to the
LEADING_ZERO= specifier values SUPPRESS, PRINT, and PROCESSOR_DEFINED, respectively.
But ifort had not yet implemented LZ as an edit descriptor in a format when I tried it last month.
2 Likes
Thanks for the good suggestions. Unfortunately none of the compilers I use support the “leading_zero” stuff yet. Something to look forward too. In the meantime, I think I’ll just fall back to my reliable “es” formatting. I had been liking the “g” editing (especially “g0”) because it would switch to “f” editing for certain number ranges which I found more readable generally, but it’s looking less and less usable to me (it has problems beyond this for Intel when using “-assume noold_e0g0_format”)
A while ago I wrote a module and test program to implement some extra options for f0 format that the compilers I was using did not supply at the time. It supports LZ, SS and SP by producing appropriate character strings. Two versions (with and without IEEE) that you may find useful are downloadable from my personal web page
https://homepages.ecs.vuw.ac.nz/~harper/fortranstuff.shtml
1 Like
The LEADING_ZERO feature (and the LZ format items) are new in F2023. It’s been a many-years complant from users that this was implementation-dependent and that there was no standard way to control this. Dan Nagle and I developed the feature for the standard.
10 Likes
ifort is deprecated: Deprecation of The Intel® Fortran Compiler Classic (ifort) - Intel Community.
You should see if ifx supports this.
ifx and ifort share the same language feature set, though at some point in the future that won’t be true. This feature is not yet supported by the Intel compiler. I am not privy to their development schedule.