edit descriptors and large exponent fields

[DataScientist]

In the second form of the e edit descriptor, ew:dee, e is an unsigned, nonzero default
integer literal constant that determines the number of digits to appear in the exponent field.
This form is obligatory for exponents whose magnitude is greater than 999.

why?

Related to this question:

error #8451: For the Gw.dEe edit descriptor, e may not be specified if w is zero.

again why?

I am aware both are mandated by the standard, but again why? This special treatment of large-exponent values creates tangible pain when outputting float whose kind is not known a priori. What makes it special and different from lower-exponent formatting?

Thank you for any insights.

[Steve_Lionel]

For your first question, if you don't specify Eee, then the maximum exponent that can be represented is 999, where the letter E is dropped from the exponent. For example, .123+999.

For your second question, the idea of w=0 is that the "processor" selects the minimum suitable values for w and e such that the value is formatted without asterisks. This part of the standard had a problem, for which I submitted an interpretation request, and the text was changed for Fortran 2023 - see j3-fortran.org/doc/year/21/21-172r1.txt

What you want here is E0.dE0, or just E0.d (at least in F2023).

[DataScientist]

Nice! I did not know `e0` is also possible (I assume it means the minimum exponent width required as wide as it may be).

I am still confused: Given your first response, does this `E0.d` mean max exponent width of 3?

[Steve_Lionel · Accepted solution]

The published F2018 standard doesn't say what happens with E0.d when the exponent is more than 99, which was the subject of my interpretation request. (Intel gets this wrong even when the exponent is not more than 99, but that's a bug I reported a while ago and is still not fixed.)

The resolution, now part of F2023 as well as F2018 Corrigendum 2, is that E0.d is treated as if it were E0.dE0, meaning that the exponent field is the minimum width necessary to represent the exponent (and not allowing removal of the exponent letter.)

[jimdempseyatthecove]

Seeing that ifx and ifort support REAL(16), exponents could reach to 5 digits. Handling more than two should be addressed.

Jim Dempsey

[DataScientist]

That is the precise problem I am dealing with right now. Limiting the default exponent range to any specific value begs the question why.

[jimdempseyatthecove]

From stackoverflow

#include <quadmath.h>
#include <iostream>
int main()
{
  char* y = new char[1000];
  quadmath_snprintf(y, 1000, "%Qf", 1.0q);
  std::cout << y << std::endl;
  return 0;
}

quadmath.h is in libquadmath.so

If you are on Windows, there may be the same implementation or someone else has one.

You'd use C interoperability to format your number to a character variable.

Jim Dempsey

[Steve_Lionel]

That real values can have large exponents is exactly why the Ee variant of edit descriptors was added a long time ago. The limit of two digits dates back to the very early days of the language. Zero w and e are newer additions that let the processor display as many digits as necessary. No C is needed.