On 25 December 2010 20:15, Marnen Laibow-Koser <li...@ruby-forum.com> wrote: > 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.
I am not at all saying there is no advantage to BigDecimal, merely exploring the issues. I entirely agree that for + - * there can be significant advantages. I am pointing out here that as soon as you get into more complex calculations involving division, or irrational numbers such as pi, and trig functions, square roots and so on that BigDecimal is not a panacea and will not guarantee that there are no errors in the calculations. >> 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. Right, again I was pointing out that one cannot blindly assume that BigDecimal is a panacea, it is necessary to understand ones problem and use the features appropriately. I am not suggesting you would not do that, others may not realise the issues however. It does seem strange to me that the default should be such low precision. It means that doing complex arithmetic with BigDecimal using the default precision one may get much greater errors than with Float. >> 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. You misunderstand me, I was talking about the possibility of BigDecimal automatically using Rationals internally when division is involved (if the division does not result in an exact result). So if one did BD(1) / BD(3) then the result would be exactly 1/3 and would be a BigDecimal. Internally it would be a Rational but the user would not need to know that. The Wikipedia article appeared to suggest that some languages automatically do that. Again I am not saying Ruby _should_ do that, merely exploring the issues again. I am not trying to have an argument here, I am learning a lot myself by researching the issues and value such discussions greatly. Did you have a chance to see whether for you the result of BD 1 / BD 3 where each was specified as 16 bit appeared to result in an 8 bit answer, and if so, why? 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.
