Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28744 Discussions

symbol E missing in output of real numbers with E0 or ES0 format descriptor

ojacquet
Novice
2,135 Views

Hello,

 

I use ifort (IFORT) 2021.3.0 20210609.

 

I do not understand why the symbol E is not written for real numbers written with the E0 and ES0 edit descriptor. And why it is written with G0...

 

double precision :: A = 1.0935E-5

 

write(6,"(E0.7)") A   !  gives : .1093500-04

write(6,"(ES0.7)") A   ! gives : 1.0935000-05

write(6,"(G0.7)") A  ! gives : .1093500E-04

 

This behavior is not described in the documentation.

These numbers written without the symbol E cannot be read with R or C++...

 

Is it a wanted behavior ?

Is it a bug ?

Is there a way to have the symbol E written ?

 

Thanks,

Olivier

1 Solution
Steve_Lionel
Honored Contributor III
2,041 Views

This has been reported to Intel. It gets even more fun when the value you're writing has a four-digit exponent - then Intel Fortran writes a exponent-number of asterisks. It turns out that the standard does not provide a meaning for this operation, which obviously a bug in the standard. I have submitted an interpretation request regarding this and the three-digit behavior.

View solution in original post

8 Replies
Steve_Lionel
Honored Contributor III
2,120 Views

An interesting question. First, the standard says:

"On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the specified value of the field width w may be zero. In such cases, the processor selects the smallest positive actual field width that does not result in a field filled with asterisks." (13.2.7.1 p1(6)"

It also says:

"On output, if an exponent exceeds its specified or implied width using the E, EN, ES, EX, D, or G edit descriptor, or the number of characters produced exceeds the field width, the processor shall fill the entire field of width w with asterisks. However, the processor shall not produce asterisks if the field width is not exceeded when optional characters are omitted"

For Ew.d, and ESw.d there is a form of the output when the exponent has three or more digits. omitting the letter, but the exponent doesn't have three digits. Gw.d should follow this rule too.

I would say this is a bug. The code is choosing to omit the exponent letter, in some cases, to satisfy the "smallest positive field width" for w=0, but this is wrong, if for no other reason than that the exponent is not outside the range -99:+99. I'd have to check to see if there's any new language for the case where the exponent is outside that range, and if not I will submit an interpretation request.

Steve_Lionel
Honored Contributor III
2,115 Views

Oh, it gets worse. I was going to suggest you write E0.7E0 - the E0 lets the compiler select the exponent width, but this also omits the letter!

ojacquet
Novice
2,096 Views

Thank you!

I would appreciate if you could report this as a bug, since this prevents the correct reading by other languages...

0 Kudos
Steve_Lionel
Honored Contributor III
2,072 Views

I will submit a bug report - Intel Fortran should not be dropping the exponent letter for an exponent whose absolute value is between 0 and 99, either for E0.d or E0.dE0.  Another bug (or maybe the same bug) has it dropping the exponent letter for E0.dEe for any value of e. 

In the process of investigating this, I found that the standard, as currently written, requires dropping the letter for E0.d when the exponent is outside that 0-99 range. I feel that this was not intended and will be submitting an interpretation request to the standards committee on it. This won't help you for now. All I can suggest in the meantime is to not use E0.d at all.

Steve_Lionel
Honored Contributor III
2,042 Views

This has been reported to Intel. It gets even more fun when the value you're writing has a four-digit exponent - then Intel Fortran writes a exponent-number of asterisks. It turns out that the standard does not provide a meaning for this operation, which obviously a bug in the standard. I have submitted an interpretation request regarding this and the three-digit behavior.

Steve_Lionel
Honored Contributor III
1,931 Views

This is being tracked internally as issue CMPLRLIBS-33536.  The Intel OSC ticket is 05214004.

ojacquet
Novice
1,909 Views
0 Kudos
Steve_Lionel
Honored Contributor III
1,492 Views

I'll comment that the behavior of E0 when the exponent is more than two digits is the subject of a F2018 interpretation request I filed, that is now part of F2018 Corrigendum 2.  See https://j3-fortran.org/doc/year/21/21-172r1.txt The problem with fewer than three digits is still broken in the latest Intel Fortran.

Reply