Colin Law wrote in post #970667: > On 25 December 2010 20:15, Marnen Laibow-Koser <li...@ruby-forum.com> > wrote: >>>> correct design. >> >> 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.
OK, that I agree with. I thought you were going further. > >>> 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. And to me. > It means > that doing complex arithmetic with BigDecimal using the default > precision one may get much greater errors than with Float. Right. > >>> 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. Is that really a good idea? This is where I think you're really arguing for a further abstraction as I already proposed. > 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'd want a symbolic math system like Mathematica to do that. I'm not sure if a general-purpose programming language should. > > I am not trying to have an argument here, I am learning a lot myself > by researching the issues and value such discussions greatly. Me too! This is fascinating. > > 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? Not yet. Even though I'm Jewish, Christmas has me really busy! > > 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.
