[#57574] [ruby-trunk - Feature #8976][Open] file-scope freeze_string directive — "akr (Akira Tanaka)" <akr@...>

70 messages 2013/10/02

[#57579] [ruby-trunk - Feature #8977][Open] String#frozen that takes advantage of the deduping — "sam.saffron (Sam Saffron)" <sam.saffron@...>

25 messages 2013/10/02

[#57679] [ruby-trunk - Feature #8987][Open] map/collect extension which handles arguments — "sowieso (So Wieso)" <sowieso@...>

16 messages 2013/10/05

[#57705] [ruby-trunk - Feature #8992][Open] Use String#freeze and compiler tricks to replace "str"f suffix — "headius (Charles Nutter)" <headius@...>

43 messages 2013/10/07

[#57727] [ruby-trunk - Feature #8998][Open] string keys for hash literals should use fstrings — "normalperson (Eric Wong)" <normalperson@...>

17 messages 2013/10/08

[#57771] [ruby-trunk - Bug #9008][Open] TestProcess#test_clock_getres_constants and TestProcess#test_clock_gettime_constants fails on ARM — "vo.x (Vit Ondruch)" <v.ondruch@...>

15 messages 2013/10/09

[#57888] [ruby-trunk - Feature #9025][Open] Clarify the error message when calling a method with the wrong number of arguments — Nerian (Gonzalo Rodríguez) <siotopo@...>

11 messages 2013/10/15

[#57993] [ruby-trunk - Feature #9047][Open] Alternate hash key syntax for symbols — "jamonholmgren (Jamon Holmgren)" <jamon@...>

13 messages 2013/10/23

[#58007] [ruby-trunk - Feature #9049][Open] Shorthands (a:b, *) for inclusive indexing — "mohawkjohn (John Woods)" <john.o.woods@...>

25 messages 2013/10/24

[#58033] [ruby-trunk - Bug #9053][Open] SSL Issue with Ruby 2.0.0 — "tisba (Sebastian Cohnen)" <ruby-lang@...>

16 messages 2013/10/25

[#58080] [ruby-trunk - Feature #9064][Open] Add support for packages, like in Java — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>

23 messages 2013/10/30

[ruby-core:58032] [ruby-trunk - Bug #7829] Rounding error in Ruby Time

From: "mpglover (Matt Glover)" <mpglover@...>
Date: 2013-10-25 03:33:57 UTC
List: ruby-core #58032
Issue #7829 has been updated by mpglover (Matt Glover).


david_macmahon (David MacMahon) wrote:
>  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.

Just wanted to second this. I came rather close to filing a bug report about, I think, the same core issue. In part because these two tests led me to believe Ruby did prefer the decimal approximation:
- https://github.com/ruby/ruby/blob/f79aeb60e7e49c0430f2685719c8c4772cfc6f95/test/ruby/test_time.rb#L57
- https://github.com/ruby/ruby/blob/f79aeb60e7e49c0430f2685719c8c4772cfc6f95/test/ruby/test_time.rb#L75

However a similar looking test fails:
> assert_equal(0, (Time.at(1.9) + 0.1).usec)
<0> expected but was <999999>.

I assume that 999999 is the expected result for reasons described earlier in the ticket. Unless/until Dave's suggestions are implemented it may be helpful to adjust those tests to make it obvious the Float-related behavior is expected.
----------------------------------------
Bug #7829: Rounding error in Ruby Time
https://bugs.ruby-lang.org/issues/7829#change-42613

Author: loirotte (Philippe Dosch)
Status: Closed
Priority: Normal
Assignee: akr (Akira Tanaka)
Category: doc
Target version: next minor
ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]
Backport: 


Even if I know the precision errors related to the implementation of IEEE 754 floating values, I'm very surprised of:

irb(main):001:0> Time.utc(1970,1,1,0,0,12.860).strftime("%H:%M:%S,%L")
=> "00:00:12,859"

The fact is that I obtain:

irb(main):002:0> Time.utc( 1970, 1, 1, 0, 0, 12.860 ).subsec
=> (60517119992791/70368744177664)
irb(main):003:0> Time.utc( 1970, 1, 1, 0, 0, 12.860 ).subsec.to_f
=> 0.8599999999999994

If I well understand the precision error that is reported for the 12th or 14th digit after the comma, I don't understand why the rounding process gives an unexpected result for this value. In this case, the last significant digit of my value is impacted, and it appears to be a embarrassing behavior. For other values, the obtained result is as expected:

irb(main):001:0> Time.utc(1970,1,1,0,0,12.880).strftime("%H:%M:%S,%L")
=> "00:00:12,880"

Moreover, this is a part of the Time class and I don't know any way to fix it in a program (and I don't know the full list of values reproducing this issue...)


-- 
http://bugs.ruby-lang.org/

In This Thread

Prev Next