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).
next prev 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: linkBe 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).