From: David MacMahon <davidm@...>
Date: 2013-04-16T16:25:40+09:00
Subject: [ruby-core:54325] Re: [ruby-trunk - Bug #7829] Rounding error in Ruby Time


On Apr 10, 2013, at 9:36 PM, Zachary Scott wrote:

> So is this a documentation bug? I haven't read the entire discussion

The discussion has wandered some from the original bug report.  I don't think there is consensus yet on the disposition of this report.  While Time's handling of Float arguments is numerically correct, it is generally inappropriate for most users (IMHO).  I would classify it as a "real" bug rather than a documentation bug.

The Time class converts Float arguments (primarily seconds and microseconds) to Rationals using Float#to_r.  Float#to_r creates a Rational that exactly represents the double precision value stored in the Float.

The problem with using Float#to_r to convert seconds (or microseconds) to Rational is that it assumes the double precision value stored in the Float is the true value (i.e. the exact value to the nearest unit of precision).  In the vast majority of cases the double precision value stored in the Float is not the true value but rather a binary approximation of the true value.

Instead of using Float#to_r to capture the Float's binary approximation of the true value as a Rational, I think it would be preferable to capture a decimal approximation of the Float as a Rational  One way to do this is to use Float#to_s to convert the seconds (or microseconds) to a decimal String approximation of the (binary approximation of the) true value, then use String#to_r to capture the decimal approximation of the Float as a Rational.

The three main reasons for preferring the decimal approximation for Float seconds (or microseconds) are:

1) No unpleasant surprises for users, especially when using Float literals as in the original bug report.

2) Almost all users will have a fairly limited decimal precision of time (i.e. milliseconds, microseconds, nanoseconds) so the decimal approximation of the Float is likely to be equal to the true value whereas the binary approximation will not be.

3) Users with very high and/or non-decimal precision of time are unlikely to be using Floats anyway.

Dave