On 25 December 2010 14:24, Marnen Laibow-Koser <li...@ruby-forum.com> wrote: > Peter Vandenabeele wrote in post #970618: >> Colin Law wrote in post #970616: >>> On 25 December 2010 00:37, Peter Vandenabeele <li...@ruby-forum.com> >>> wrote: >> ... >>>> I am not in favor of D because it silently changes the class >>>> of the result and this violates the principle of least surprise. >>>> If you want Rational, use it from the start then. >>> >>> For D there is no reason why the class of the result needs to change >>> to Rational. It could stay as BigDecimal but internally store the >>> data as a Rational. > > In this case there would be no advantage to storing as a Rational. > Sounds like you want an ExactNumber class that abstracts both. > > For the record, I think BigDecimal / BigDecimal = BigDecimal is the > correct design.
In an earlier post I think it was suggested that an advantage of BigDecimal is that errors do not increase. With divide as it is, and choosing 16 digit accuracy, then BigDecimal is virtually identical to Float (assuming ruby Float is actually what would be known as double in C). Also errors will potentially increase every time a divide operation is performed. It seems that the default is actually 8 digit which is only single precision float accuracy. I see that http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic discusses exactly this problem and the use of Rationals to get around it. It seems to suggest that some languages do that. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
