# Question regarding the "g" edit descriptor **URL:** \ **Category:** Uncategorized\ **Created:** [December 14, 2023, 3:18pm UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992 "2023-12-14T15:18:00Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![nncarlson](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/nncarlson/32/1175_2.png) [@nncarlson](https://fortran-lang.discourse.group/u/nncarlson)\ **Post date:** [December 14, 2023, 3:18pm UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/1 "2023-12-14T15:18:01Z")
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. ---
**Author:** ![jeff.irwin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeff.irwin/32/3673_2.png) [@jeff.irwin](https://fortran-lang.discourse.group/u/jeff.irwin)\ **Post date:** [December 14, 2023, 4:52pm UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/2 "2023-12-14T16:52:20Z")
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](https://community.intel.com/t5/Intel-Fortran-Compiler/Leading-zeros-in-the-f0-x-format-descriptor/td-p/1175148) [Dr. Fortran has said](https://community.intel.com/t5/Intel-Fortran-Compiler/Leading-zeros-in-the-f0-x-format-descriptor/m-p/1175154#M147197): > 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 ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [December 14, 2023, 6:02pm UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/4 "2023-12-14T18:02:10Z")
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. ---
**Author:** ![Harper](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@Harper](https://fortran-lang.discourse.group/u/Harper)\ **Post date:** [December 14, 2023, 8:29pm UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/5 "2023-12-14T20:29:35Z")
See also F2023 section 13.8.5, which begins thus: ```auto 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. ---
**Author:** ![nncarlson](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/nncarlson/32/1175_2.png) [@nncarlson](https://fortran-lang.discourse.group/u/nncarlson)\ **Post date:** [December 15, 2023, 5:33am UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/6 "2023-12-15T05:33:34Z")
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”) ---
**Author:** ![Harper](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@Harper](https://fortran-lang.discourse.group/u/Harper)\ **Post date:** [December 15, 2023, 8:45am UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/7 "2023-12-15T08:45:35Z")
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` ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [December 16, 2023, 1:17am UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/8 "2023-12-16T01:17:09Z")
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. ---
**Author:** ![JeffH](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jeffh/32/595_2.png) [@JeffH](https://fortran-lang.discourse.group/u/JeffH)\ **Post date:** [December 18, 2023, 4:37am UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/9 "2023-12-18T04:37:23Z")
> [@Harper](#): > > ```auto > > ``` > > But ifort had not yet implemented LZ as an edit descriptor in a format when I tried it last month. `ifort` is deprecated: [Deprecation of The Intel® Fortran Compiler Classic (ifort) - Intel Community](https://community.intel.com/t5/Blogs/Tech-Innovation/Tools/Deprecation-of-The-Intel-Fortran-Compiler-Classic-ifort/post/1541699). You should see if `ifx` supports this. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [December 18, 2023, 5:03pm UTC](https://fortran-lang.discourse.group/t/question-regarding-the-g-edit-descriptor/6992/10 "2023-12-18T17:03:47Z")
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.