Colin Law wrote in post #970648: > On 25 December 2010 14:24, Marnen Laibow-Koser <li...@ruby-forum.com> > wrote: >>>> 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.
Basically. > 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). Not at all! You can't store 397 significant figures in a Float. You can in a BigDecimal. Apparently you are wilfully ignoring this advantage, since it has been brought up several times already. > 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. > So don't use the default! Sheesh. > 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. And that would be easy to do in Ruby. I'm glad we have a choice, though. > > Colin Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- 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.
