Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: Date: Wed, 6 Jul 2005 04:06:09 -0400 From: Lev Bishop Reply-To: Lev Bishop To: cygwin AT cygwin DOT com Subject: Re: SV: Bug in printf ? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20430_15248170.1120637169788" References: <6879888 DOT 1120133556579 DOT JavaMail DOT adm-moff AT moffice2 DOT nsc DOT no> ------=_Part_20430_15248170.1120637169788 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I don't think there is any bug here. This is what I've seen from a little digging: 1) cygwin strtod rounds to even, with about DECIMAL_DIG (=3D=3D21) digits precision, as recommended by 7.20.1.3 of WG14/N843. (It acts strange when the rounding mode is not round to nearest, but since newlib doesn't provide fesetround(), that's your own problem if you insist on changing rounding mode by hand, as I understand it). 2) cygwin gcc rounds with *lots* more precision than DECIMAL_DIG, about 50 digits. It rounds towards zero. These behaviours are a little different than the recommendation in 6.4.4.2 Ibid., which says constants should be converted as if by strtod() at runtime, but its not a big difference. 3) cygwin printf correctly rounds to even, even out to about 41 digits. 4) I have no idea what mingw is doing, but it's different to the above. Gcc constructs the same double precision constants as on cygwin but strtod() is different and seems to have less precision, and printf() seems to work with about 16 digits precision. At a glance I'd say it rounds to zero, with exactly the precision of On 05/07/05, Dave Korn wrote: > Stepping through the code at the weekend, I followed the 0.105 case as f= ar > down as ldtoa_r, where I observed that although there was code that would > round 0.105 up to 0.11 if asked for only two sig.figs, the loop that > generates successive digits was coming up with the sequence > '0.10499999999.....', and because the rounding only looks at one digit > beyond the requested s.f., it 'correctly' rounds 0.104 down to 0.10. The closest double to 0.105 is actually 0.10499999999999999611421941381195210851728916168212890625, and this is what printf() is (correctly) handed, and what it (correctly) rounds to 0.10. =20 > I say 'correctly' in quotes, because it's the correct way to round 0.104, > but it's not in general correct to round a number by truncating it and th= en > rounding the truncated version. But I don't think that "truncating it and then rounding the truncated version" is what printf() does. If we give it 0.125 and 0.375, which are both representible exactly, then it rounds to 0.12 and 0.38, ie one goes up and one goes down, to round to even. You can see it's not simply truncating if you give it 0.1250000000000001, which gets rounded to 0.13 not 0.12 as it would for truncation. To summarize: cygwin does the right thing ------=_Part_20430_15248170.1120637169788 Content-Type: text/plain; name="test.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test.c" I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1 ZGUgPG1hdGguaD4KI2luY2x1ZGUgPGZsb2F0Lmg+CgojaWZkZWYgX19NSU5H VzMyX18KI2luY2x1ZGUgPGZlbnYuaD4KI2VuZGlmCgoKLy8gc2hvdyB0aGUg aGV4IGFuZCBkZWNpbWFsIGludGVycHJldGF0aW9ucyBvZiB0aGUgZG91Ymxl CnVuaW9uIFV7ZG91YmxlIGQ7dW5zaWduZWQgY2hhciBjWzhdO307CnZvaWQg ZGlzcGxheSh1bmlvbiBVIHgpCnsKICBmb3IoaW50IGI9NztiPj0wO2ItLSlw cmludGYoIiUwMngiLHguY1tiXSk7CiAgcHJpbnRmKCIgJS4yMWYiLHguZCk7 Cn0KCgppbnQgbWFpbihpbnQgYXJnYywgY29uc3QgY2hhcioqYXJndikKewoK I2lmZGVmIF9fTUlOR1czMl9fCiAgaWYgKGFyZ2MgPj0gMikKICAgIHsKICAg IGludCBucm0sIG47CiAgICAgICAgbiA9IHNzY2FuZiAoYXJndlsxXSwgIiVp IiwgJm5ybSk7CiAgICAgICAgaWYgKG4gPT0gMSkgc3dpdGNoIChucm0pCiAg ICAgICAgewogICAgICAgICAgICBjYXNlIDA6CiAgICAgICAgICAgIGNhc2Ug MHg0MDA6CiAgICAgICAgICAgIGNhc2UgMHg4MDA6CiAgICAgICAgICAgIGNh c2UgMHhjMDA6CiAgICAgICAgICAgICAgICBmZXNldHJvdW5kIChucm0pOwog ICAgICAgIH0KICAgIH0KCiAgcHJpbnRmICgiUm1vZGUgJCUwOHhcbiIsIGZl Z2V0cm91bmQgKCkpOwojZW5kaWYKCiAgcHJpbnRmKCJERUNJTUFMX0RJRz0l ZFxuIixERUNJTUFMX0RJRyk7CgojZGVmaW5lIFBBU1RFKHgpIHsucz0jeCwu ZDE9c3RydG9kKCN4LDApLC5kMj14fQogIHN0cnVjdCBTIHtjb25zdCBjaGFy KnM7dW5pb24gVSBkMSxkMjt9cVtdPQogICAgewogICAgICAvLyB0ZXN0IHRo ZSByb3VuZGluZyB3aXRoIHRoZSBsYXN0IGRpZ2l0cy4uLgogICAgICAvLyBm aXJzdCByaWdodCBvbiB0aGUgYm91bmRhcnksIHRvIHRlc3Qgcm91bmQtdG8t ZXZlbgogICAgICBQQVNURSgxLjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDApLCAvLyAxCiAgICAgIFBB U1RFKDEuMDAwMDAwMDAwMDAwMDAwMTExMDIyMzAyNDYyNTE1NjU0MDQyMzYz MTY2ODA5MDgyMDMxMjUwMCksIC8vIDEgKyAyXi01MwogICAgICBQQVNURSgx LjAwMDAwMDAwMDAwMDAwMDIyMjA0NDYwNDkyNTAzMTMwODA4NDcyNjMzMzYx ODE2NDA2MjUwMDApLCAvLyAxICsgMl4tNTIKICAgICAgUEFTVEUoMS4wMDAw MDAwMDAwMDAwMDAzMzMwNjY5MDczODc1NDY5NjIxMjcwODk1MDA0MjcyNDYw OTM3NTAwKSwgLy8gMSArIDJeLTUyICsyXi01MwogICAgICB7MH0sCiAgICAg IC8vIG5vdyBqdXN0IGFib3ZlIHRoZSBib3VuZGFyeQogICAgICBQQVNURSgx LjAwMDAwMDAwMDAwMDAwMDAwMDAxKSwKICAgICAgUEFTVEUoMS4wMDAwMDAw MDAwMDAwMDAxMTEwMyksCiAgICAgIFBBU1RFKDEuMDAwMDAwMDAwMDAwMDAw MjIyMDUpLAogICAgICBQQVNURSgxLjAwMDAwMDAwMDAwMDAwMDMzMzA3KSwK ICAgICAgezB9LAogICAgICAvLyBub3cganVzdCBiZWxvdyB0aGUgYm91bmRh cnkKICAgICAgUEFTVEUoMC45OTk5OTk5OTk5OTk5OTk5OTk5OSksCiAgICAg IFBBU1RFKDEuMDAwMDAwMDAwMDAwMDAwMTExMDEpLAogICAgICBQQVNURSgx LjAwMDAwMDAwMDAwMDAwMDIyMjA0KSwKICAgICAgUEFTVEUoMS4wMDAwMDAw MDAwMDAwMDAzMzMwMSksCiAgICAgIHswfSwKICAgICAgUEFTVEUoMC4xMDUp LAogICAgfTsKIAogIHByaW50ZigiICAgICAgICAgICAgICAgICAxLjIzNDU2 Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwXG4iKTsgLy8gZm9yIGNvdW50aW5n IHNpZyBmaWdzCiAgZm9yKGludCBhPTA7YTxzaXplb2YocSkvc2l6ZW9mKHN0 cnVjdCBTKTthKyspCiAgICB7CiAgICAgIGlmKCFxW2FdLnMpe3ByaW50Zigi XG4iKTtjb250aW51ZTt9CiAgICAgIGRpc3BsYXkocVthXS5kMSk7CiAgICAg IHByaW50ZigiICIpOwogICAgICBkaXNwbGF5KHFbYV0uZDIpOwogICAgICBw cmludGYoIlxuIik7CiAgICB9CiAgCiAgcHJpbnRmKCJcbiIpOwoKICB1bmlv biBVIHdbXT17MC4xMDUsMC4xMTUsMC4xMjUsMC4xMzUsMC4xNDUsMC4xNTUs MC4zNzV9OwogIGZvcihpbnQgYT0wO2E8c2l6ZW9mKHcpL3NpemVvZih1bmlv biBVKTthKyspCiAgICB7CiAgICAgIGRpc3BsYXkod1thXSk7CiAgICAgIHBy aW50ZigiXG4iKTsKICAgIH0KCiAgcHJpbnRmKCIlLjQwZlxuIiwwLjEwNSk7 CgogIC8vIGhlcmUncyBzb21lIG51bWJlcnMgd2l0aCBhbiBleGFjdCByZXBy ZXNlbnRhdGlvbiBpbiBkb3VibGUKICBwcmludGYoIiUuMjBmICUuMmZcbiIs LjEyNSwuMTI1KTsgCiAgcHJpbnRmKCIlLjIwZiAlLjJmXG4iLC4zNzUsLjM3 NSk7IAogIHByaW50ZigiJS4yMGYgJS4xM2ZcbiIsMC45NTM2NzQzMTY0MDYy NTAwMDAwMCwwLjk1MzY3NDMxNjQwNjI1MDAwMDAwKTsKICBwcmludGYoIiUu MjBmICUuMTdmXG4iLDMuNTA5Njg1NTE2MzU3NDIxODc1MCwzLjUwOTY4NTUx NjM1NzQyMTg3NTApOyAvLyAxICsgNjU3ODk5LzJeMTgKICBwcmludGYoIiUu MjBmICUuMTVmXG4iLC0xLjUwMzUzMjQwOTY2Nzk2ODc1MDAsLTEuNTAzNTMy NDA5NjY3OTY4NzUwMCk7CgogIC8vIGhvdyBtYW55IGRpZ2l0cyBwcmVjaXNp b24gZG9lcyBnY2MgdXNlIHdoZW4gbWFraW5nIGRvdWJsZSBjb25zdGFudHM/ CiAgZGlzcGxheSgodW5pb24gVSl7LmQ9MS4wMDAwMDAwMDAwMDAwMDAzMzMw NjY5MDczODc1NDY5NjIxMjcwODk1MDA0MjcyNDZ9KTsKfQoKLy8gVXNlZnVs IE1hdGhlbWF0aWNhIHN0dWZmLi4uCi8qCiAgVGFibGVbe3gvMTAwMC4sCiAg ICAgICAgICAgIEJhc2VGb3JtW0Zyb21EaWdpdHNbUmVhbERpZ2l0c1sjMiwg Ml0gLy8gRmlyc3QgLy8gUmVzdCwgMl0sIDE2XSwKICAgICAgICAgICAgTlsj MioyXigtNTMgKyAjW1syXV0pLAogICAgICAgICAgICAgIDQxXX0gJlsjLAog ICAgICAgIENlaWxpbmdbRnJvbURpZ2l0c1sjW1sxXV0sIDJdLwogICAgICAg ICAgICAyXV0gJltSZWFsRGlnaXRzW3gvMTAwMCwgMiwgNTRdXSwge3gsIDEw NSwgMTU1LCAxMH1dCgoqLwo= ------=_Part_20430_15248170.1120637169788 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ------=_Part_20430_15248170.1120637169788--