public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "thenlich at users dot sourceforge.net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/47945] REAL(8) output conversion error on MinGW32
Date: Wed, 02 Mar 2011 06:45:00 -0000	[thread overview]
Message-ID: <bug-47945-4-5JWS61Sdqn@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47945-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945

Thomas Henlich <thenlich at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor

--- Comment #6 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-03-02 06:45:01 UTC ---
I still think it makes sense to demand that the same binary value always
converts to the same decimal number, regardless of compiler vendor, or
platform.

It should even be the same for the same internal value, when the variables are
of different real kinds (which now it isn't, on mingw). Consider:

real(8) :: r8
real(16) :: r16

r8 = .14285714285714286d0
r16 = r8
write(*, '(f35.32)') r8
write(*, '(f35.32)') r16
end

output:
 0.14285714285714284921875000000000
 0.14285714285714284921269268124888

Sometimes it is necessary to specify more decimal digits than necessary in the
edit descriptor because the magnitude of the result may vary. Now, if the same
binary value would always result in the same decimal number, that would make it
easier to compare results obtained from the same program, obtained with two
different compilers or on different platforms (a method used for program
verification).

The Fortran 2008 standard even demands this behaviour (in my interpretation):

===
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. [etc]
===

In the example, 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...).

The point is, what the standard demands is the closest approximation that can
be represented with the specified output precision.

The standard does not state that an implementation may truncate the result
after an arbitrary number of decimal digits (even if that number is higher than
the possible precision of the internal bit width used).


  parent reply	other threads:[~2011-03-02  6:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 14:00 [Bug libfortran/47945] New: " thenlich at users dot sourceforge.net
2011-03-01 14:01 ` [Bug libfortran/47945] " thenlich at users dot sourceforge.net
2011-03-01 14:02 ` thenlich at users dot sourceforge.net
2011-03-01 14:28 ` schwab@linux-m68k.org
2011-03-01 14:45 ` thenlich at users dot sourceforge.net
2011-03-02  0:22 ` jvdelisle at gcc dot gnu.org
2011-03-02  6:45 ` thenlich at users dot sourceforge.net [this message]
2011-03-02  7:14 ` kargl at gcc dot gnu.org
2011-03-02  7:25 ` burnus at gcc dot gnu.org
2011-03-02 13:49 ` thenlich at users dot sourceforge.net
2011-03-02 16:45 ` burnus at gcc dot gnu.org
2011-03-02 17:04 ` burnus at gcc dot gnu.org
2011-03-02 17:54 ` thenlich at users dot sourceforge.net
2011-03-02 18:02 ` burnus at gcc dot gnu.org
2011-03-02 18:17 ` sgk at troutmask dot apl.washington.edu
2011-03-03 14:04 ` jb at gcc dot gnu.org
2011-03-03 14:58 ` thenlich at users dot sourceforge.net
2011-03-04  6:48 ` thenlich at users dot sourceforge.net
2011-03-04  6:53 ` thenlich at users dot sourceforge.net
2011-03-04  6:54 ` thenlich at users dot sourceforge.net
2011-03-04  6:57 ` thenlich at users dot sourceforge.net

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-47945-4-5JWS61Sdqn@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).