public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: 1.7.8: Fortran I/O rounding inaccuracy
@ 2011-03-07 13:18 Thomas Henlich
  2011-03-07 13:52 ` Tim Prince
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Henlich @ 2011-03-07 13:18 UTC (permalink / raw)
  To: cygwin

> I doubt our compiler is Fortran 2008 compliant, as at maximum it will
> be Fortran 2003

An identical phrase appears in Fortran 2003.

> Have you tested gfortran 4.3 on other platform ?

Due to unavailability, I was not able to test this particular version
on other platforms.

Tested ok:

gfortran 4.4 on Debian
gfortran snapshot 20101129 on mingw32

Bug confirmed:

gfortran snapshot 20100408 (unofficial Cygwin build)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07 13:18 1.7.8: Fortran I/O rounding inaccuracy Thomas Henlich
@ 2011-03-07 13:52 ` Tim Prince
  0 siblings, 0 replies; 9+ messages in thread
From: Tim Prince @ 2011-03-07 13:52 UTC (permalink / raw)
  To: cygwin

On 3/7/2011 4:17 AM, Thomas Henlich wrote:
>> I doubt our compiler is Fortran 2008 compliant, as at maximum it will
>> be Fortran 2003
>
> An identical phrase appears in Fortran 2003.
>
>> Have you tested gfortran 4.3 on other platform ?
>
> Due to unavailability, I was not able to test this particular version
> on other platforms.
>
> Tested ok:
>
> gfortran 4.4 on Debian
> gfortran snapshot 20101129 on mingw32
>
> Bug confirmed:
>
> gfortran snapshot 20100408 (unofficial Cygwin build)
>

You haven't shown how you tested rounding modes UP or DOWN, which may 
not be implemented in gfortran, as those (I believe) require the 
IEEE_arithmetic module, which is still under development.  Doesn't the 
wording you quote apply to the binary value resulting from READ conversion?
In the default (without IEEE_arithmetic settings), it's not clear to me 
that f2003 or 2008 standards impose requirements beyond those of 
IEEE754, which allow the decimal representation to truncate after 17 
correct digits.
As Corinna said, the place to ask about progress in this area of 
gfortran is fortran@gcc.org.
Corinna is more of an expert on newlib than are we; the differences you 
quote between linux implementation on glibc and cygwin which you quote 
appear to be within newlib.

-- 
Tim Prince

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07 18:26     ` Peter Brown
@ 2011-03-07 19:13       ` Roger K. Wells
  0 siblings, 0 replies; 9+ messages in thread
From: Roger K. Wells @ 2011-03-07 19:13 UTC (permalink / raw)
  To: cygwin

On 03/07/2011 12:15 PM, Peter Brown wrote:
> Roger K. Wells<ROGER.K.WELLS<at>  saic.com>  writes:
>
>> On 03/07/2011 10:44 AM, Roger K. Wells wrote:
>>> On 03/07/2011 04:39 AM, Thomas Henlich wrote:
>>>> Hi,
>>>>
>>>> I found the following bug in cygwin 1.7.8 on Windows XP:
>>>>
>>>> Fortran I/O rounding truncates the result after a certain number of
>>>> digits. The following program:
>>>> ===
>>>> write(*, '(f35.32)') 0.14285714285714285d0
>>>> end
>>>> ===
>>>> gives this output:
>>>>    0.14285714285714284921269000000000
>>>> The expected output is:
>>>>    0.14285714285714284921269268124888
>>>>
> I don't think this has anything to do with cygin. On our linux system I get
>
> With Intel ifort:
>   0.14285714285714284921269268124888
>
> With gfortran 4.1.2s544
>   0.14285714285714284921269270000000
>
I agree.  It's a GCC problem.  I get the same results on Cygwin & Linux:
compiling with g77 gives correct output
compiling with gfortran does not.
rkw
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>


-- 
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@saic.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07 16:38   ` Roger K. Wells
@ 2011-03-07 18:26     ` Peter Brown
  2011-03-07 19:13       ` Roger K. Wells
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Brown @ 2011-03-07 18:26 UTC (permalink / raw)
  To: cygwin

Roger K. Wells <ROGER.K.WELLS <at> saic.com> writes:

> 
> On 03/07/2011 10:44 AM, Roger K. Wells wrote:
> > On 03/07/2011 04:39 AM, Thomas Henlich wrote:
> >> Hi,
> >>
> >> I found the following bug in cygwin 1.7.8 on Windows XP:
> >>
> >> Fortran I/O rounding truncates the result after a certain number of
> >> digits. The following program:
> >> ===
> >> write(*, '(f35.32)') 0.14285714285714285d0
> >> end
> >> ===
> >> gives this output:
> >>   0.14285714285714284921269000000000
> >> The expected output is:
> >>   0.14285714285714284921269268124888
> >>

I don't think this has anything to do with cygin. On our linux system I get

With Intel ifort:
 0.14285714285714284921269268124888

With gfortran 4.1.2s544
 0.14285714285714284921269270000000



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07 15:54 ` Roger K. Wells
@ 2011-03-07 16:38   ` Roger K. Wells
  2011-03-07 18:26     ` Peter Brown
  0 siblings, 1 reply; 9+ messages in thread
From: Roger K. Wells @ 2011-03-07 16:38 UTC (permalink / raw)
  To: cygwin

On 03/07/2011 10:44 AM, Roger K. Wells wrote:
> On 03/07/2011 04:39 AM, Thomas Henlich wrote:
>> Hi,
>>
>> I found the following bug in cygwin 1.7.8 on Windows XP:
>>
>> Fortran I/O rounding truncates the result after a certain number of
>> digits. The following program:
>> ===
>> write(*, '(f35.32)') 0.14285714285714285d0
>> end
>> ===
>> gives this output:
>>   0.14285714285714284921269000000000
>> The expected output is:
>>   0.14285714285714284921269268124888
>>
>> This is in violation of the Fortran 2008 standard which demands:
>>
>> ===
>> 10.7.2.3.7 I/O rounding mode
>>
>> 2. In what follows, the term "decimal value" means the exact decimal 
>> number as
>> given by the character string, while the term "internal value" means 
>> the number
>> actually stored in the processor.  For example, in dealing with the 
>> decimal
>> constant 0.1, the decimal value is the mathematical quantity 1/10, 
>> which has no
>> exact representation in binary form.  Formatted output of real data 
>> involves
>> conversion from an internal value to a decimal value; formatted input 
>> involves
>> conversion from a decimal value to an internal value.
>>
>> 3.  When the I/O rounding mode is UP, the value resulting from 
>> conversion shall
>> be the smallest representable value that is greater than or equal to the
>> original value. When the I/O rounding mode is DOWN, the value resulting
>> from conversion shall be the largest representable value that is less 
>> than or
>> equal to the original value. ...
>> ===
>>
>> Applied to the example this means, 0.14285714285714284921269268124888
>> is the largest representable
>> (with 32 decimal digits) value that is less than the original value 
>> (binary
>> 1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
>> 0.1428571428571428492126926812488818...), but
>> 0.14285714285714284921269000000000 is NOT.
>>
>> The problem seems limited to the Fortran language, because the C call
>> printf("%35.32f\n", 0.14285714285714285) prints the expected result:
>>   0.14285714285714284921269268124888
>>
>> -- 
>> Problem reports:       http://cygwin.com/problems.html
>> FAQ:                   http://cygwin.com/faq/
>> Documentation:         http://cygwin.com/docs.html
>> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>>
>>
> uname -a: CYGWIN_NT-6.1 rwells-w7 1.7.8(0.236/5/3) 2011-03-01 09:36 
> i686 Cygwin
>
> round.f:
>       program round
>       write(*,'(f35.32)') 0.14285714285714285d0
>       end
>
> output:
>  0.14285714285714284921269268124888
>
> did I miss something?
answer to my own question: yes

if compiling with g77
     output: 0.14285714285714284921269268124888

if compiling with gfortran:
     output: 0.14285714285714284921269000000000

a bit of a surprise.

rkw
>
> HTH,
> roger wells
>
>
>


-- 
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@saic.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07  9:55 Thomas Henlich
  2011-03-07 10:40 ` marco atzeri
  2011-03-07 11:13 ` Corinna Vinschen
@ 2011-03-07 15:54 ` Roger K. Wells
  2011-03-07 16:38   ` Roger K. Wells
  2 siblings, 1 reply; 9+ messages in thread
From: Roger K. Wells @ 2011-03-07 15:54 UTC (permalink / raw)
  To: cygwin

On 03/07/2011 04:39 AM, Thomas Henlich wrote:
> Hi,
>
> I found the following bug in cygwin 1.7.8 on Windows XP:
>
> Fortran I/O rounding truncates the result after a certain number of
> digits. The following program:
> ===
> write(*, '(f35.32)') 0.14285714285714285d0
> end
> ===
> gives this output:
>   0.14285714285714284921269000000000
> The expected output is:
>   0.14285714285714284921269268124888
>
> This is in violation of the Fortran 2008 standard which demands:
>
> ===
> 10.7.2.3.7 I/O rounding mode
>
> 2. In what follows, the term "decimal value" means the exact decimal number as
> given by the character string, while the term "internal value" means the number
> actually stored in the processor.  For example, in dealing with the decimal
> constant 0.1, the decimal value is the mathematical quantity 1/10, which has no
> exact representation in binary form.  Formatted output of real data involves
> conversion from an internal value to a decimal value; formatted input involves
> conversion from a decimal value to an internal value.
>
> 3.  When the I/O rounding mode is UP, the value resulting from conversion shall
> be the smallest representable value that is greater than or equal to the
> original value. When the I/O rounding mode is DOWN, the value resulting
> from conversion shall be the largest representable value that is less than or
> equal to the original value. ...
> ===
>
> Applied to the example this means, 0.14285714285714284921269268124888
> is the largest representable
> (with 32 decimal digits) value that is less than the original value (binary
> 1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
> 0.1428571428571428492126926812488818...), but
> 0.14285714285714284921269000000000 is NOT.
>
> The problem seems limited to the Fortran language, because the C call
> printf("%35.32f\n", 0.14285714285714285) prints the expected result:
>   0.14285714285714284921269268124888
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>
uname -a: CYGWIN_NT-6.1 rwells-w7 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 
Cygwin

round.f:
       program round
       write(*,'(f35.32)') 0.14285714285714285d0
       end

output:
  0.14285714285714284921269268124888

did I miss something?

HTH,
roger wells



-- 
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@saic.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07  9:55 Thomas Henlich
  2011-03-07 10:40 ` marco atzeri
@ 2011-03-07 11:13 ` Corinna Vinschen
  2011-03-07 15:54 ` Roger K. Wells
  2 siblings, 0 replies; 9+ messages in thread
From: Corinna Vinschen @ 2011-03-07 11:13 UTC (permalink / raw)
  To: cygwin

On Mar  7 10:39, Thomas Henlich wrote:
> Hi,
> 
> I found the following bug in cygwin 1.7.8 on Windows XP:
> 
> Fortran I/O rounding truncates the result after a certain number of
> digits. The following program:
> ===
> write(*, '(f35.32)') 0.14285714285714285d0
> end
> ===
> gives this output:
>  0.14285714285714284921269000000000
> The expected output is:
>  0.14285714285714284921269268124888
> [...]
> The problem seems limited to the Fortran language, because the C call
> printf("%35.32f\n", 0.14285714285714285) prints the expected result:
>  0.14285714285714284921269268124888

So it's not a Cygwin bug after all.  It's a bug in the GNU fortran
compiler or one of its libraries.  You should ask about this in a GNU
fortran mailing list, perhaps.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: 1.7.8: Fortran I/O rounding inaccuracy
  2011-03-07  9:55 Thomas Henlich
@ 2011-03-07 10:40 ` marco atzeri
  2011-03-07 11:13 ` Corinna Vinschen
  2011-03-07 15:54 ` Roger K. Wells
  2 siblings, 0 replies; 9+ messages in thread
From: marco atzeri @ 2011-03-07 10:40 UTC (permalink / raw)
  To: cygwin

On Mon, Mar 7, 2011 at 10:39 AM, Thomas Henlich  wrote:
> Hi,
>
> I found the following bug in cygwin 1.7.8 on Windows XP:
>
> Fortran I/O rounding truncates the result after a certain number of
> digits. The following program:
> ===
> write(*, '(f35.32)') 0.14285714285714285d0
> end
> ===
> gives this output:
>  0.14285714285714284921269000000000
> The expected output is:
>  0.14285714285714284921269268124888
>
> This is in violation of the Fortran 2008 standard which demands:

I doubt our compiler is Fortran 2008 compliant, as at maximum it will
be Fortran 2003
http://gcc.gnu.org/gcc-4.3/changes.html

>
> ===
> 10.7.2.3.7 I/O rounding mode
>
> 2. In what follows, the term "decimal value" means the exact decimal number as
> given by the character string, while the term "internal value" means the number
> actually stored in the processor.  For example, in dealing with the decimal
> constant 0.1, the decimal value is the mathematical quantity 1/10, which has no
> exact representation in binary form.  Formatted output of real data involves
> conversion from an internal value to a decimal value; formatted input involves
> conversion from a decimal value to an internal value.
>
> 3.  When the I/O rounding mode is UP, the value resulting from conversion shall
> be the smallest representable value that is greater than or equal to the
> original value. When the I/O rounding mode is DOWN, the value resulting
> from conversion shall be the largest representable value that is less than or
> equal to the original value. ...
> ===
>
> Applied to the example this means, 0.14285714285714284921269268124888
> is the largest representable
> (with 32 decimal digits) value that is less than the original value (binary
> 1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
> 0.1428571428571428492126926812488818...), but
> 0.14285714285714284921269000000000 is NOT.
>
> The problem seems limited to the Fortran language, because the C call
> printf("%35.32f\n", 0.14285714285714285) prints the expected result:
>  0.14285714285714284921269268124888
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

Have you tested gfortran 4.3 on other platform ?

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

* 1.7.8: Fortran I/O rounding inaccuracy
@ 2011-03-07  9:55 Thomas Henlich
  2011-03-07 10:40 ` marco atzeri
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Thomas Henlich @ 2011-03-07  9:55 UTC (permalink / raw)
  To: cygwin

Hi,

I found the following bug in cygwin 1.7.8 on Windows XP:

Fortran I/O rounding truncates the result after a certain number of
digits. The following program:
===
write(*, '(f35.32)') 0.14285714285714285d0
end
===
gives this output:
 0.14285714285714284921269000000000
The expected output is:
 0.14285714285714284921269268124888

This is in violation of the Fortran 2008 standard which demands:

===
10.7.2.3.7 I/O rounding mode

2. In what follows, the term "decimal value" means the exact decimal number as
given by the character string, while the term "internal value" means the number
actually stored in the processor.  For example, in dealing with the decimal
constant 0.1, the decimal value is the mathematical quantity 1/10, which has no
exact representation in binary form.  Formatted output of real data involves
conversion from an internal value to a decimal value; formatted input involves
conversion from a decimal value to an internal value.

3.  When the I/O rounding mode is UP, the value resulting from conversion shall
be the smallest representable value that is greater than or equal to the
original value. When the I/O rounding mode is DOWN, the value resulting
from conversion shall be the largest representable value that is less than or
equal to the original value. ...
===

Applied to the example this means, 0.14285714285714284921269268124888
is the largest representable
(with 32 decimal digits) value that is less than the original value (binary
1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal
0.1428571428571428492126926812488818...), but
0.14285714285714284921269000000000 is NOT.

The problem seems limited to the Fortran language, because the C call
printf("%35.32f\n", 0.14285714285714285) prints the expected result:
 0.14285714285714284921269268124888

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-03-07 18:26 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-07 13:18 1.7.8: Fortran I/O rounding inaccuracy Thomas Henlich
2011-03-07 13:52 ` Tim Prince
  -- strict thread matches above, loose matches on Subject: below --
2011-03-07  9:55 Thomas Henlich
2011-03-07 10:40 ` marco atzeri
2011-03-07 11:13 ` Corinna Vinschen
2011-03-07 15:54 ` Roger K. Wells
2011-03-07 16:38   ` Roger K. Wells
2011-03-07 18:26     ` Peter Brown
2011-03-07 19:13       ` Roger K. Wells

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).