From: Zachary Scott <zachary@...>
Date: 2013-04-11T13:36:34+09:00
Subject: [ruby-core:54167] Re: [ruby-trunk - Bug #7829] Rounding error in Ruby Time

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

On Tue, Apr 9, 2013 at 2:24 AM, David MacMahon
<davidm@astro.berkeley.edu> wrote:
>
> On Apr 5, 2013, at 3:34 PM, Tanaka Akira wrote:
>
>> 57563.232824357045 is not representable as a Float.
>
> Sorry, poor wording on my part.  What I meant was that the Float created from the floating point literal 57563.232824357045 is displayed by #inspect and #to_s as "57563.232824357045".  IOW, calling #to_s on the 57563.232824357045 literal returns a string that represents the same value as the literal even though the underlying bits store a different value.  This is not true for all literals.  For example, calling #to_s on the literal 57563.232824357044 will also return the string "57563.232824357045".
>
> Essentially, Float#to_s returns the shortest decimal string (or one of several equally short strings) that is not closer to any other Float value.  A Rational that exactly equals the value represented by that decimal string is also not closer to any other Float value, so converting it to Float via #to_f would be expected to return the original Float value, but that is not always the case.
>
>> f.to_r.to_f == f is true.
>
> Yes, I now realize that this will always be true.  Even though Rational#to_f rounds the numerator and denominator to double precision before dividing and then rounds the quotient after dividing, this will never cause problems for Rationals created via Float#to_r (assuming Bignum#to_f works sanely) due to the way Float.to_r works.
>
> I would also like f.to_s.to_r.to_f == f to always be true.  This is is not always the case because f.to_s.to_r has factors of 2 and 5 in the denominator, so the reduced Rational in this case runs the risk of #to_f not returning the closest approximation to the original value.  In extreme cases, f.to_s.to_r.to_f can return values two representable values away from the original:
>
>>> f1=4.7622749438937484e-07
> => 4.7622749438937484e-07
>>> f2=4.762274943893749e-07
> => 4.762274943893749e-07
>>> f1 < f2
> => true
>
> After converting to String then to Rational then back to Float, f2 retains its original value, but f1 becomes larger than f2!
>
>>> f1srf=f1.to_s.to_r.to_f
> => 4.7622749438937494e-07
>>> f2srf=f2.to_s.to_r.to_f
> => 4.762274943893749e-07
>>> f1srf > f2srf <== NB: GREATER THAN
> => true
>
> Getting back to the original post, Time.new converts its "seconds" parameter using num_exact(), which converts Floats (among other types) to Rational using #to_r.  It then divmod's the value by 1 to get integer seconds and fractional seconds.  The complaint in the original post was that using the literal 12.68 for the seconds parameter led Time#strftime's %L specifier to show 679 milliseconds rather than 680.
>
> In an earlier post, I suggested modifying num_exact to convert Floats to Rational via Float#rationalize, but now I think that converting to String and then to Rational (or preferably a more direct approach that does the equivalent) would lead to the best user experience.
>
> Converting Floats passed as "seconds" using Float#to_r assumes that people have 53 bits of precision in their "seconds" values.  I suspect that this is not true for the vast majority of users.  More likely they have millisecond, microsecond, or maybe nanosecond precision.  People with higher (or non-decimal) precision will (or at least should, IMHO) be using Rationals already.  Converting Float "seconds" to String and then to Rational makes the most sense (IMHO) as it preserves the decimal precision of the input.  The (debatable) rounding issue of Rational#to_f is not really problematic for this use case since it does not affect values that are likely to be used for seconds.
>
> Dave
>
>