From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIms-0000vC-ND for qemu-devel@nongnu.org; Thu, 21 Jan 2016 12:12:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMImp-0004iW-Gh for qemu-devel@nongnu.org; Thu, 21 Jan 2016 12:12:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMImp-0004iS-8h for qemu-devel@nongnu.org; Thu, 21 Jan 2016 12:12:43 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id E0182C0AA378 for ; Thu, 21 Jan 2016 17:12:42 +0000 (UTC) References: <1453219845-30939-1-git-send-email-eblake@redhat.com> <1453219845-30939-2-git-send-email-eblake@redhat.com> <87si1s1v4u.fsf@blackfin.pond.sub.org> <569FADED.3030307@redhat.com> <87k2n3ihaa.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <56A11189.3020209@redhat.com> Date: Thu, 21 Jan 2016 10:12:41 -0700 MIME-Version: 1.0 In-Reply-To: <87k2n3ihaa.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ilwCqqs8MiQaF26LKUNs6KhPw6moBLpTq" Subject: Re: [Qemu-devel] [PATCH v9 01/37] qobject: Document more shortcomings in our number handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: marcandre.lureau@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ilwCqqs8MiQaF26LKUNs6KhPw6moBLpTq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/20/2016 11:21 PM, Markus Armbruster wrote: >> One alternative is to always output a guaranteed unambiguous decimal >> string (although not necessarily the shortest), by using %.17f, using >> DBL_DECIMAL_DIG. (Note that DBL_DIG of 15 is NOT sufficient= - >> it is the lower limit that says that a decimal->float->decimal will no= t >> change the decimal; but we want the converse where a >> float->decimal->float will not change the float. There are stretches = of >> numbers where the pigeonhole principle applies; you can think of it th= is >> way: there is no way to map all possible 2^10 (1024) binary values >> inside 2^3 (1000) decimal digits without at least 24 of them needing o= ne >> more decimal digit. But by the same arguments, DBL_DECIMAL_DIG is an >> upper limit and usually more than you need.) >> >> So, the question is whether we want to always output 17 digits, or >> whether we want to do the poor-man's truncation scheme (easy to >> understand, but not optimal use of the processor), or go all the way t= o >> the algorithm of that paper (faster but lots harder to understand). F= or >> reference, here's the poor-man's algorithm in pseudocode: >=20 > I don't think we want to implement floating-point formatting ourselves.= Well, we already have _some_ level of floating-point support built in for TCG emulation of floating point on various architectures. I don't know how much would be easily reusable for this case, though. >=20 >> if 0, inf, nan: >> special case >> else: >> Obtain the DBL_DECIMAL_DIG string via sprintf %.17f >> i =3D 17; >> do { >> truncate the original string to i-1 decimal characters >> parse that with strtod() >> if the bit pattern differs: >> break; >> } while (--i); >> assert(i) >> use i digits of the string >=20 > That's a lot of strtod()... May not be noticable if we write the resul= t > to a slowish sink. Binary search could save a few. >=20 > Naive idea: chop off trailing '0'? That, and rounding trailing '9'. Any other digits in positions 1-16 are significant (other digits in position 17 might not matter, though), so I guess a full 17 iterations is probably not strictly necessary. Our current code DOES chop trailing '0', but starting from the flawed premise that 6 digits was enough precision. >=20 >> As a separate patch, of course, but I have a pending patch that provid= es >> a single place where we could drop in such an improvement: >> https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg03932.html >=20 > Definitely separate. Okay, all thoughts for a later day :) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ilwCqqs8MiQaF26LKUNs6KhPw6moBLpTq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWoRGJAAoJEKeha0olJ0NqyS4H/0rtVDO2LaV1KzwLTqeRX0dn e9nVu2qNbFWsQK6Vd+ey3CJEtUlJPNdZIZ8MF3QDnQbLfJiRNimP8TIOegXhZnPF N5KGC0xutjAdSzheWX4IV5R6+EXhV0Y7iVuAvuD7GLB7IcwaFeqtaaya1wf7ob5c uVXmUKWlaI60amcQ/+cD+iMyMvVnfUJfcoJnH2rAFJM7/BMvjA0kvQ2ms7zzE/KP 96+jfjJiniK3KpWurlrPXIe88SELO7w2xrti6io2D3BAL2N1j6ANZdPKn5J8Lgdi DOfEcuUDsRRATR9IbMXS5fDW/dv8ripFC5HrYDdwgaHMR5AbKVsfJJaWZCbiHPI= =IjMO -----END PGP SIGNATURE----- --ilwCqqs8MiQaF26LKUNs6KhPw6moBLpTq--