Paul Eggert wrote on 1998-10-12 06:21 UTC:
Date: Sun, 11 Oct 1998 12:22:03 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
(double) ((t1.sec - t2.sec) + (t1.nsec - t2.nsec) / 1.0e9)
where t?.sec is at least 64-bit int and t?.nsec is at least 32-bit int.
Can you really construct input values that will lead to your claimed double rounding error
Sure. Let's use the Sparc IEEE implementation, which straightforwardly maps `double' to IEEE 64-bit double, and let's assume round-to-even, which is the IEEE default. Then here are example input values:
t1.sec = 9007199254740993 (i.e. 2**53 + 1) t1.nsec = 1000000000 (i.e. 10**9) t2.sec = t2.nsec = 0
The exact answer is 9007199254740994 (i.e. 2**53 + 2), a number that is exactly representable as an IEEE double. But the expression above yields 9007199254740992 (i.e. 2**53) -- it is off by 2.
Come on, that is a value 0.28 billion years from now. Do you have a non-pathologic case, where you do not fill up the double mantissa completely? We define non-pathological as follows: Clive Feather was just here in the Lab, and one of the things he said certainly needs to be changed is that the struct xtime requirement int_fast64_t sec; int_fast32_t nsec; has to be relaxed to require sec only to represent roughly all values from the start of the year -9999 to the end of the year +9999 ("proleptic Gregorian calendar in astronomical integer year notation" for the nitpickers ;-). This includes all ISO 8601 representable time stamps, the Julian Date origin, the limits of the accuracy of the Gregorian calendar, the entire recorded human history ("recorded" meaning "written documents have been found"), and should therefore be OK for >>99% of all applications. This range requires a bit less than 40 bits for sec, and then we do not care about rounding errors in IEEE double if sec is not a 40-bit representable integer. A few other things Clive mentioned: The language of my draft is not acceptable and needs a major rewrite to become an ISO proposal. It has to be prefixed with a convincing and very easy to read tutorial with some usage examples (which will later become part of the rationale) that introduces readers to concepts and problem areas such as leap seconds and time zones and clearly motivates every proposed feature (whereas my text at the moment was more written for people with a long experience in the field and gives just pointers into the literature). The *real* problems are more related to how we present the new proposal to the committee and actually getting it through, and not so much to all the more bizarre technical things we have been discussing here over the past few days. In other words, we should be much more concerned about the PR aspects of the proposal than about very technical details and esoteric clock models, otherwise this will stay an academic exercise. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>