Content-Type: multipart/mixed; boundary="------------010608020705040109080408" This is a multi-part message in MIME format. --------------010608020705040109080408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/1/2011 19:01, Peter Rockett wrote: > On 01/05/11 08:43, Keith Marshall wrote: >> On 30/04/11 23:14, Kai Tietz wrote: >>> long double (80-bit): >>> digits for mantissa:64 >>> digit:18, min exp:-16381 (-4931 10th) >>> max exp: 16384 (4932 10th) >>> Epsilon:1.0842e-019 >>> >>> Which means that indeed the accuracy of 20 digits after decimal point= >>> are pretty precise here. >=20 > I've followed with some unease at the way "accuracy" and "precision"=20 > have been used in this thread. To nuance Keith's point below, you can=20 > write down 20 digits after the decimal point but that does not mean you= =20 > have 20-digit accuracy. They are very different things. >=20 >> You cannot get 20 decimal digits precision after the decimal point, wi= th >> 80-bit floating point. You cannot even get 20 significant digit >> precision -- there is a subtle but extremely important distinction. T= he >> best you can hope for is 19 significant digits. >=20 > So long doubles don't do normalisation, and thus have no extra, implici= t=20 > mantissa bit? (Have come across something that suggests this as an=20 > historical quirk but it was unclear.) That would set long doubles apart= =20 > from singles and doubles in the IEEE754 scheme of things... Interesting= =2E >=20 > To add my two pennyworth on pow/sqrt: Although changing the behaviour o= f=20 > pow() to give the same answer as sqrt() for the special case of 0.5 may= =20 > seem like a good idea, this is potentially introducing a discontinuity = > into pow() which could be disastrous. Fundamentally, why should you=20 > expect two transcendental quantities calculated in different ways with = > finite-precision arithmetic to give exactly the same result? Floats are= =20 > not real numbers! In fact some of the comparisons in this thread have=20 > involved differences of a few ulps (units of least precision) - which=20 > looks really good to me. Good point, does only 0.5 get special treatment? What of 0.25 or 0.499...= =2E? I think those concerned with accuracy and precision over performance should be using something more specialized like GMP/MPFR arbitrary precision libraries, with the C library (libmingwex in this case) providing a "good enough" and "fast enough" implementation. Slightly OT: Arbitrary precision square root: --------------010608020705040109080408 Content-Type: application/pgp-keys; name="0xED74C077.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xED74C077.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.16 (MingW32) mQGiBEoX6mARBACDkWLtpoOo/ZGtzDJBx1Q7+/np5ILeJJVwsXsBmBnqslmzfOMA G8u1AqjBgGaY5PFlTHF4hXKfq1Y9c5EDJYLIG0Et9EE7CpOBpGqAL9HrrudErCyZ Gc4/iJuvIhWldhsNmpsuXch69fsM3Vh2OstGhO90WQGkZ5drmOZEowxSBwCglPps Cfte3WYQa1tmhnQOSR2cYbMD/Ri4mqOn21Y2X2V3/3HE0Lk6f6a9Azp4BiD5+dJv 3d5vvYEf2/oPlY8Q0xx2Mp1bULRdN1HKIVLtqrRzAdOtE4m31W2xQEIbFYk9ij7x YDBoOGam3iQ/nz9X/pka7fWIr/pdyIOZmx9a+hc2jehdOUfQNX4o0j+eMJ1DVRXQ TeJLA/4v3fhLb7HYI6hv0h0RZKRzWxnqQs9JtOWvvgC/lg/A4M3+MLkZ5NBrGiJI Eu889x+um9FNuuttO0m4G+ADt9r8oWlUrX7pMq+Z5f9stl9tITSmV07CGQeb/dse X3R/pZmxj0bQP8UJ4XEdgAs7sFNuG43eTGO6fJqvOVn5EIvPhbQjam9uX3kgPGpv bl95QHVzZXJzLnNvdXJjZWZvcmdlLm5ldD6IYAQTEQIAIAUCShfqYAIbAwYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEKeegCntdMB3q4MAn3r9hhW6BHQOqkDzd7hS G4qCzVvzAJ9auqMimmrdJznw9WadoZRoup1iZrkCDQRKF+pgEAgAykLcD/2U6vck 4l+E6Uyv4S7UuqXG/+KWz7CLZo4Pez/7k+32HLKwMvmlwoLc9YOM9LaPGjOR4xPN eVH6kFkd+p0DXy5bSEpbO/ZXFGSA+PwJD/uITIu2kKv4tNh1YwaIgdnxUxaw6dVv fvmG45hNGetZBVARrT3G7XT9MAEDjaEuXJVwJbD16bjKw88sK2s/DNVFGsnYcrUL EM2dtCMtCrV6c0jLWe5oatfrYwT5HX0nA57Xnnwz4Ipe0vUSnl/wrbwhqQCnYLlm apVu+P9DBvBRZ0YzgsIJNu5QKJE2aeoRDMP5gdm+YlIhG3PEaKGXPGuNXqwrnICR Up63C6Ss6wADBgf/XMg955hahDrjDZ2aZuf2IxkafCZk1HIxl1UcilJ8dOgSeBmC /h1Uqxbe0ibzsgg2n/r+oMvU510vnvhcCAUdRiWYBluN7VPzKGo9megwhZpnGXcI 7WweogiwdFxwP5mqqTYpmL1Qc6NdRewE3VAEoOO2fQkJicAoO2zfhEtx1JL1DTwY Y1TDOriihOs2FX1zPUn8T0hSTPQwGP108ZNOSYeE3zSNko0uOMHwmn4A6R5ZQW9k GX+EiTOm9zBqMhZgHHeFkme/rPXHagh/MG8PiIWVBYucUWDe5DUb6TV4r7dKLZFS 0o0uWSMHo1hQeyBuGXJPpRZERMoDXcUVMnAd0YhJBBgRAgAJBQJKF+pgAhsMAAoJ EKeegCntdMB3OQYAnjvSniU2qAHp4dkKZCOl1xLgKy9nAJ9JXl+cxyjgsuPaVU1q O0yvIxAf/Q=3D=3D =3Da1qp -----END PGP PUBLIC KEY BLOCK----- --------------010608020705040109080408--