strange results when reading real*16 from strings

Hi all,

in gfortran 4.7.0 under both WinXPx32 and Win7x64 I get strange results when trying to read a variable declared as real*16 from a string. Using identical code in gfortran 4.6.1 under Ubuntu11.10x64 yields results that agree perfectly with that obtained when using ifort (as of 2011) except that an input error occurs with gfortran under both Win and Linux when a "Q" precedesthe exponent. ifort gets that right, too.

Does somebody use gfortran with quad precision and list directed input under Windows and can comment on the reuslts, please?

Code follows below, here are some results:

------------SOME WINDOWS RESULTS---------------
Pi as F-string : 3.141592653589793238462643383279502884197
Pi from F-string : 3.14159265431748983635574439809831049

Pi as D-string : 3.141592653589793238462643383279502884197D0
Pi from D-string : 3.14159265431748983635574439809831049

Pi as Q-string : 3.141592653589793238462643383279502884197Q0
Pi from Q-string : reading from string failed with IOSTAT = 5010

Pi from 4*atn1-Q : 3.14159265358979323846264338327950280

XX as D-string : 1.0000000000000000000000000000000000000D-30
XX from D-string : 1.00000000022995876584157513400149540E-0030

XX as Q-string : 1.0000000000000000000000000000000000000Q-30
XX from Q-string : reading from string failed with IOSTAT = 5010

XX from F-number : 1.00000000317107685097105134713526475E-0030
XX from E-number : 1.00000000317107685097105134713526475E-0030
XX from D-number : 1.00000000000000008333642060758598535E-0030
XX from Q-number : 9.99999999999999999999999999999999997E-0031
------------WINDOWS RESULTS---------------

------------SOME LINUX GCC RESULTS---------------
Pi as F-string : 3.141592653589793238462643383279502884197
Pi from F-string : 3.1415926535897932384626433832795028

Pi as D-string : 3.141592653589793238462643383279502884197D0
Pi from D-string : 3.1415926535897932384626433832795028

Pi as Q-string : 3.141592653589793238462643383279502884197Q0
Pi from Q-string : reading from string failed with IOSTAT = 5010

Pi from 4*atn1-Q : 3.1415926535897932384626433832795028

XX as F-string : 0.000000000000000000000000000001000000000
XX from F-string : 9.99999999999999999999999999999999997E-0031

XX as D-string : 0.000000000000000000000000000001000000000D0
XX from D-string : 9.99999999999999999999999999999999997E-0031

XX as Q-string : 0.000000000000000000000000000001000000000Q0
XX from Q-string : reading from string failed with IOSTAT = 5010

XX as 1.0Q-30 : 9.99999999999999999999999999999999997E-0031
------------LINUX GCC RESULTS---------------

------------SOME LINUX IFORT RESULTS---------------
Pi as F-string : 3.141592653589793238462643383279502884197
Pi from F-string : 3.14159265358979323846264338327950

Pi as D-string : 3.141592653589793238462643383279502884197D0
Pi from D-string : 3.14159265358979323846264338327950

Pi as Q-string : 3.141592653589793238462643383279502884197Q0
Pi from Q-string : 3.14159265358979323846264338327950

Pi from 4*atn1-Q : 3.14159265358979323846264338327950

XX as F-string : 0.000000000000000000000000000001000000000
XX from F-string : 1.000000000000000000000000000000000E-0030

XX as D-string : 0.000000000000000000000000000001000000000D0
XX from D-string : 1.000000000000000000000000000000000E-0030

XX as Q-string : 0.000000000000000000000000000001000000000Q0
XX from Q-string : 1.000000000000000000000000000000000E-0030

XX as 1.0Q-30 : 1.000000000000000000000000000000000E-0030

------------LINUX IFORT RESULTS---------------

program readqp
implicit none
real*16 myqua
integer ioerr
character*43 mystr

mystr='3.141592653589793238462643383279502884197 '
write(6,*) ' Pi as F-string : ',mystr
read(mystr,*) myqua
write(6,*) 'Pi from F-string : ',myqua
write(6,*) ' '

mystr(42:43)='E0'
write(6,*) ' Pi as E-string : ',mystr
read(mystr,*) myqua
write(6,*) 'Pi from E-string : ',myqua
write(6,*) ' '

mystr(42:43)='D0'
write(6,*) ' Pi as D-string : ',mystr
read(mystr,*) myqua
write(6,*) 'Pi from D-string : ',myqua
write(6,*) ' '

mystr(42:43)='Q0'
write(6,*) ' Pi as Q-string : ',mystr
read(mystr,*,IOSTAT=ioerr,err=1) myqua
1 if (ioerr.eq.0) then
write(6,*) 'Pi from Q-string : ',myqua
else
write(6,*) 'Pi from Q-string : reading from string ',
& 'failed with IOSTAT = ',ioerr
endif
write(6,*) ' '

myqua=4.0Q0*atan(1.0Q0)
write(6,*) 'Pi from 4*atn1-Q : ',myqua
write(6,*) ' '
write(6,*) ' '
write(6,*) ' '

mystr='0.000000000000000000000000000001000000000 '
write(6,*) ' XX as F-string : ',mystr
read(mystr,*) myqua
write(6,*) 'XX from F-string : ',myqua
write(6,*) ' '

mystr='1.0000000000000000000000000000000000000 '
mystr(40:43)='E-30'
write(6,*) ' XX as E-string : ',mystr
read(mystr,*) myqua
write(6,*) 'XX from E-string : ',myqua
write(6,*) ' '

mystr(40:40)='D'
write(6,*) ' XX as D-string : ',mystr
read(mystr,*) myqua
write(6,*) 'XX from D-string : ',myqua
write(6,*) ' '

mystr(40:40)='Q'
write(6,*) ' XX as Q-string : ',mystr
read(mystr,*,IOSTAT=ioerr,err=2) myqua
2 if (ioerr.eq.0) then
write(6,*) 'XX from Q-string : ',myqua
else
write(6,*) 'XX from Q-string : reading from string ',
& 'failed with IOSTAT = ',ioerr
endif
write(6,*) ' '

myqua=0.000000000000000000000000000001000000000
write(6,*) 'XX from F-number : ',myqua
myqua=1.0000000000000000000000000000000000000E-30
write(6,*) 'XX from E-number : ',myqua
myqua=1.0000000000000000000000000000000000000D-30
write(6,*) 'XX from D-number : ',myqua
myqua=1.0000000000000000000000000000000000000Q-30
write(6,*) 'XX from Q-number : ',myqua

stop
end

On 4/19/2012 4:41 PM, derStroehleinSchorsch wrote:
> in gfortran 4.7.0 under both WinXPx32 and Win7x64 I get strange results when trying to read a
> variable declared as real*16 from a string. Using identical code in gfortran 4.6.1 under
> Ubuntu11.10x64 yields results that agree perfectly with that obtained when using ifort (as of 2011)
> except that an input error occurs with gfortran under both Win and Linux when a "Q" precedes the exponent.
> ifort gets that right, too.

Just a reminder - an exponent letter of Q is non-standard. For input,
either E or D works and has the same effect. It may be that gfortran
requires some option to allow Q, or it may not support it. My advice is
to stick to E in formatted input for floating point values. You can use
D if you want. Remember also that there is no output format that gives
you a Q exponent letter. The only place Q can be useful is in literal
constants, but that was before the introduction of KIND.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/arti...ization-notice
for more information regarding performance and optimization choices in
Intel software products.

Steve Lionel <steve.lionel@intel.invalid> wrote:
> On 4/19/2012 4:41 PM, derStroehleinSchorsch wrote:
>> in gfortran 4.7.0 under both WinXPx32 and Win7x64 I get strange
>> results when trying to read a variable declared as real*16
>> from a string. Using identical code in gfortran 4.6.1 under
(snip)
>> under both Win and Linux when a "Q" precedes the exponent.
>> ifort gets that right, too.

> Just a reminder - an exponent letter of Q is non-standard.
> For input, either E or D works and has the same effect.

As far as I know, REAL*16 first became available in the IBM
Fortan H Extended (not regular H) compiler. Extended precision
started on the 360/85 and then was standard on S/370 and later
models.

(snip)
> Remember also that there is no output format that gives
> you a Q exponent letter. The only place Q can be useful is in
> literal constants, but that was before the introduction of KIND.

I believe that VAX/VMS supports REAL*16 and Q format, if no
other reason than for IBM compatibility. (H float was done
in software emulation on most VAX models, some with microcode
as an extra cost item. I believe it was standard on the 11/730.
At least I was told it was on the one I knew about.

Systems that write out Q should also accept it on input, but
otherwise one should normally use E for input of any precision.

-- glen

On Apr 19, 3:23*pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Systems that write out Q should also accept it on input, but
> otherwise one should normally use E for input of any precision.
>
> -- glen

I have never seen a Fortran implementation write Q for
an exponent when writing under a numeric edit descriptor.
Have there been any such implementations? I recall an
implementation that used D for an exponent, even when
writing under an E edit descriptor, but that was a long
time ago.

Bob Corbett

robert.corbett@oracle.com wrote:

(snip)

>> Systems that write out Q should also accept it on input, but
>> otherwise one should normally use E for input of any precision.

> I have never seen a Fortran implementation write Q for
> an exponent when writing under a numeric edit descriptor.
> Have there been any such implementations? I recall an
> implementation that used D for an exponent, even when
> writing under an E edit descriptor, but that was a long
> time ago.

I started up my IA64/VMS system to try it out, but it seems
not to have the Q format descriptor or, if it does, it does
something else. It does have REAL*16 and QSQRT().
Printing REAL*16 values with list directed output generates E
exponents.

I have the IBM Fortran manual, but the H Extended compiler is
still a licensed product, and I don't have one. The manual
describes the Q format descriptor generating Q exponents,
and they are allowed in constants in the source program.

I do wonder about VAX/VMS, but my system isn't running,
or ready to run, right now.

-- glen

On Fri, 20 Apr 2012 10:11:33 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> robert.corbett@oracle.com wrote:
>
> (snip)
>
>>> Systems that write out Q should also accept it on input, but
>>> otherwise one should normally use E for input of any precision.
>
>> I have never seen a Fortran implementation write Q for
>> an exponent when writing under a numeric edit descriptor.
>> Have there been any such implementations? I recall an
>> implementation that used D for an exponent, even when
>> writing under an E edit descriptor, but that was a long
>> time ago.
>
> I started up my IA64/VMS system to try it out, but it seems
> not to have the Q format descriptor or, if it does, it does
> something else. It does have REAL*16 and QSQRT().
> Printing REAL*16 values with list directed output generates E
> exponents.
>
> I have the IBM Fortran manual, but the H Extended compiler is
> still a licensed product, and I don't have one. The manual
> describes the Q format descriptor generating Q exponents,
> and they are allowed in constants in the source program.
>
> I do wonder about VAX/VMS, but my system isn't running,
> or ready to run, right now.

I have an old VAX Fortran manual. It does not seem to mention the Q
format descriptor generating Q exponents.

Brian.

> -- glen


--
Brian Salter-Duke Melbourne, Australia
My real address is b_duke(AT)bigpond(DOT)net(DOT)au
Use this for reply or followup
"A good programmer can write Fortran in any language"

On 4/19/2012 6:23 PM, glen herrmannsfeldt wrote:
> I believe that VAX/VMS supports REAL*16 and Q format, if no
> other reason than for IBM compatibility. (H float was done
> in software emulation on most VAX models, some with microcode
> as an extra cost item. I believe it was standard on the 11/730.
> At least I was told it was on the one I knew about.
>
> Systems that write out Q should also accept it on input, but
> otherwise one should normally use E for input of any precision.

I know, probably better than anyone else nowadays, what VAX Fortran did
here, as I implemented its run-time library support of REAL*16 and was
compiler project leader for more than five years.

[Historical sidebar - H-float was first supported as an option for the
VAX-11/780 - the codename for this option was "Twinkle" (the 780's
codename was "Star"). Implementation was a combination of microcode and
backplane rewiring. It was also a microcode option on the 750. The 730
was the first to have "native" support for H (and G) floating - though
the 730 was the slowest VAX at that time, it had the fastest
implementation of H-float due to its use of FPGAs, and I think
maintained that crown until the VAX 8600 was released. VAX G and H
float were similar in precision and range to the later IEEE double and
quad formats, but used VAX floating (derived from PDP-11/44) layout
conventions. End of history lesson.]

There was no Q ever written in floating point output by VAX Fortran, nor
by any of the later DEC, Compaq and Intel compilers. You had your
choice of E or D. There was (and is) a Q format edit descriptor
supported as an extension, but it does something completely different
(stores number of characters left in a record on formatted input.)

The only place you would see Q as an exponent letter in VAX Fortran (and
its successors) is in a floating point literal in program source. Since
Fortran 77 did not have "kind values", you needed some way to
distinguish among single, double and quad precision in constants. The
standard provided E and D for single and double, and VAX Fortran, I
think like IBM Fortran before it, used Q. But when you wrote out
REAL*16 values in formatted, list-directed or NAMELIST output, you got E
for an exponent letter (unless you used D format). Never Q. These
compilers would accept Q on input, however, for consistency with the
source literal syntax.

If you find an implementation that writes out a Q exponent letter, then
sure, it should accept it on input. But otherwise, accepting Q on input
is an extension that should not be assumed to be implemented.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/arti...ization-notice
for more information regarding performance and optimization choices in
Intel software products.

Steve Lionel <steve.lionel@intel.invalid> wrote:

(snip, I wrote)
>> I believe that VAX/VMS supports REAL*16 and Q format, if no
>> other reason than for IBM compatibility. (H float was done
>> in software emulation on most VAX models, some with microcode
>> as an extra cost item. I believe it was standard on the 11/730.
>> At least I was told it was on the one I knew about.

>> Systems that write out Q should also accept it on input, but
>> otherwise one should normally use E for input of any precision.

> I know, probably better than anyone else nowadays, what VAX Fortran did
> here, as I implemented its run-time library support of REAL*16 and was
> compiler project leader for more than five years.

> [Historical sidebar - H-float was first supported as an option for the
> VAX-11/780 - the codename for this option was "Twinkle" (the 780's
> codename was "Star"). Implementation was a combination of microcode and
> backplane rewiring. It was also a microcode option on the 750. The 730
> was the first to have "native" support for H (and G) floating - though
> the 730 was the slowest VAX at that time, it had the fastest
> implementation of H-float due to its use of FPGAs, and I think
> maintained that crown until the VAX 8600 was released. VAX G and H
> float were similar in precision and range to the later IEEE double and
> quad formats, but used VAX floating (derived from PDP-11/44) layout
> conventions. End of history lesson.]

For some years, I was working with a group that had three 11/750's
and one 11/730. Accounts were assigned separately for each, and
pretty much no-one used the 730. There was, however, the story that
it was faster for H-float, in case anyone wanted to use it for that.
I never knew anyone to do it.

I believe the 730 is build from AMD2900 series, bit-slice chips.

> There was no Q ever written in floating point output by VAX Fortran, nor
> by any of the later DEC, Compaq and Intel compilers. You had your
> choice of E or D. There was (and is) a Q format edit descriptor
> supported as an extension, but it does something completely different
> (stores number of characters left in a record on formatted input.)

DEC often implemented the IBM extensions in their compilers, though
there were many more DEC extensions than IBM extensions.

I don't remember using a Q, but it seems slightly familiar that
there was a Q that did something different in one (or more) of the
older DEC compilers. Then VAX, with the choice between an IBM
extension and DEC extension, presumably went for the DEC extension.
I never knew an IBM compiler with O (octal) format. VAX/VMS
implemented the Z (hex) descriptor that IBM did use, along with
the Z form of hex constants in DATA statements.

I was trying to figure out the meaning of the error message from
the VMS compiler, but couldn't figure it out.

> The only place you would see Q as an exponent letter in VAX Fortran (and
> its successors) is in a floating point literal in program source. Since
> Fortran 77 did not have "kind values", you needed some way to
> distinguish among single, double and quad precision in constants. The
> standard provided E and D for single and double, and VAX Fortran, I
> think like IBM Fortran before it, used Q. But when you wrote out
> REAL*16 values in formatted, list-directed or NAMELIST output, you got E
> for an exponent letter (unless you used D format). Never Q. These
> compilers would accept Q on input, however, for consistency with the
> source literal syntax.

I pretty much learned Fortran from the IBM reference manual.
One of the favorite early programs at the time was a square root
table. After reading the manual, I wanted to make a REAL*16 table,
using QSQRT and Q format, but it turned out (as I found many years
later) that only H extended has that feature, not G and regular H.

> If you find an implementation that writes out a Q exponent letter, then
> sure, it should accept it on input. But otherwise, accepting Q on input
> is an extension that should not be assumed to be implemented.

Seems right to me.

-- glen

In article <9vd8dnFt5mU1@mid.individual.net>, Steve Lionel
<steve.lionel@intel.invalid> writes:

> I know, probably better than anyone else nowadays, what VAX Fortran did
> here, as I implemented its run-time library support of REAL*16 and was
> compiler project leader for more than five years.

Indeed, and what a great compiler it was! (Still is, of course, though
I have moved on to F95 and ALPHA. I'm hoping that F95 will meet my
needs since AFAIK there is no newer standard supported on VMS. Only
recently I ran into a minor point which could be done more elegantly
with F2003.)

Am 20.04.2012 21:27, schrieb Phillip Helbig---undress to reply:
> In article<9vd8dnFt5mU1@mid.individual.net>, Steve Lionel
> <steve.lionel@intel.invalid> writes:
>
>> I know, probably better than anyone else nowadays, what VAX Fortran did
>> here, as I implemented its run-time library support of REAL*16 and was
>> compiler project leader for more than five years.
>
> Indeed, and what a great compiler it was! (Still is, of course, though
> I have moved on to F95 and ALPHA. I'm hoping that F95 will meet my
> needs since AFAIK there is no newer standard supported on VMS. Only
> recently I ran into a minor point which could be done more elegantly
> with F2003.)

Well, you could use GCC 4.8 (incl. gfortran) on (Open)VMS, cf.
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00160.html

Tobias

In article <4F91BD4F.9030204@net-b.de>, Tobias Burnus <burnus@net-b.de>
writes:

> Well, you could use GCC 4.8 (incl. gfortran) on (Open)VMS, cf.
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00160.html

Yes, that's been mentioned here, and I'll investigate it. Of course, it
won't have the VMS debugger etc. :-|

Thank you all very much for your comments. Unfortunately, I still
cannot find any way of how to read a quad precision number from a
string using gfortran470 under Windows (x32 or x64). Moreover, it is
imho inconsistent that Esyyyy_16 is standard for specifying quad
numerical input but causes a read error (IOSTAT: gfortran->5010, ifort-
>59, in both Windows and Linux) when it appears at the end of a string
that represents a number. On the other hand, under Linux (x64) strings
ending on Esyyyy (the canonical quad output form) are correctly casted
to quad numbers by both ifort2011 and gfortran461 as well.

So the bug most probably seems to be located somewhere in the Windows-
MinGW-GCC-communication rather than in the core GCC-gfortran system, I
suppose.

Thanks again
Schorsch

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> One of the favorite early programs at the time was a square root
> table. After reading the manual, I wanted to make a REAL*16 table,
> using QSQRT and Q format, but it turned out (as I found many years
> later) that only H extended has that feature, not G and regular H.

I have not heard of the Extended H version but that doesn't mean anything. I
do have G&H available. If you have a small sample we can test it under
regular FORTRAN H and see if it works.

derStroehleinSchorsch <derstroehleinschorsch@googlemail.com> wrote:

> Thank you all very much for your comments. Unfortunately, I still
> cannot find any way of how to read a quad precision number from a
> string using gfortran470 under Windows (x32 or x64). Moreover, it is
> imho inconsistent that Esyyyy_16 is standard for specifying quad
> numerical input but causes a read error...

That apparent inconsistency is actually what the standard says, and
there are reasons for it. Kind numbers are about internal
representations. As such, they make sense in Fortran source code, but
not in formatted data files. In a formatted data file, a number such as
12345 is just plain the mathematical number 12345. Well, actually, it is
just those characters, but it can be interpreted as the number. It
doesn't have anything to do with internal representations.

The internal representation is what the value is converted to (or from)
by the formatted read (or write). But you don't need anything in the
data field to tell the compiler about what kind to use for that part. It
has the io-list item for that. In Fortran source code, it is not
possible in general to deduce what kind is intended, so you have to
specify it. Formatted I/O is different.

Note also, by the way, that no, _16 is not standard for specifying quad
precision. Kind numbers are not specified by the standard. 16 is a
fairly common choice, but not a universal one, and definitely not a
standarde one. I have used compilers where quad precision real was kind
3 (because it was the 3rd real kind). That's more than just a side
notpick here. Rather that is part of why kind numbers don't go well with
formatted data files. The only reasonably portable standard ways to
specify kind numbers involve using named constants. But a named constant
is only part of the source code. It doesn't apply to data files. So if
one was to allow kind numbers in formatted data fields, they would
probably have to be restricted to literal numbers, which are not
portable and are also not consistent with what is usually recommended as
good coding style.

I can't tell you whether gfortran correctly supports quad precision
input at all. But if it does, the correct way to put the quad precision
number in the string is to not specify the precision in the string at
all. Just make the I/O list item the appropriate kind. That *IS* what
the standard says to do; it is not just a gfortran matter.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

On 4/21/2012 9:22 AM, derStroehleinSchorsch wrote:
....

> Moreover, I obviously mis-interpreted the content of this Intel web
> page:
> http://software.intel.com/sites/prod...s/rfcrealr.htm
....

NB that the section(s) referring to a Q format are in a different
shading indicating they are an Intel compiler extension _NOT_ Standard
Fortran. (Hence, expecting that to work other than for a compiler
supporting the particular extension is certain to lead to
disappointment. )

--