Thanks for looking into that Vincent. My 2 cents, for what it is worth: - NEVER use floating point for equality checks. Ever. Not only is the precision misleading (Radix 2 - isms/ etc.), but 32 vs. 64 ... etc. get in the way, quite often, in fact - If NSDate in particular, "always use NSDate methods of time calculations whenever possible" else - to_i (as Vincent lists) On Wed, 2 Feb 2011 08:20:40 +0900 Vincent Isambart <vincent.isambart@gmail.com> wrote:
My conclusions, - 0.7 and 0.9 fix return the correct time now, 0.9 fix can't do necessary time arithmetic - Ruby Time.to_f is broken in all 3 versions - Bignum.to_f is broken in all 3 versions - I believe the to_f method is behind all of these problems but i haven't had time to find the problem nor a solution.
Your problems with #to_f are due to the fact that 32-bit MacRuby stores floats in 30 bits (MRI stores them in objects in 64 bits, 64-bit MacRuby stores them in 62 bits). The reason is mainly speed related (and we also don't have to garbage-collect them). At some time I think we had 32-bit mode using objects for storing them like MRI, and 64-bit mode using 62 bits but we decided to handle them the same way in both modes to have less code to maintain.
Seeing that very few people using 32-bit (and we will probably stop "supporting" it after 0.9), you will never get the precision you want from them. What you can do with MacRuby's current state though: - if you don't need sub-second precision, use #to_i and do computations in integers (you can us Time.at to bring them back in Time instances), - if you really need sub-second prevision, you would have to use BigDecimal. To convert a Time into BigDecimal: BigDecimal.new("%d.%06d" % [time.tv_sec, time.tv_usec]). To convert a BigDecimal back to time: Time.at(bd.to_i, (bd * 1000000).to_i % 1000000) _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel