Just a footnote to all of this. The difference between using a value for pi of 3.1415927 or 3.14159265, between 7 and 8 digits of precision, when calculating the circumference of the earth introduces a difference of less than a meter. All very reasonable, but I still found it surprising.
I was taking a differential equations class from a very knowledgeable math professor who told us about it. He was also surprised to discover that such low precision in *pi* can lead to such precision in the physical world. Fred On Sat, Dec 25, 2010 at 5:30 PM, Marnen Laibow-Koser <li...@ruby-forum.com>wrote: > 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<rubyonrails-talk%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- 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.
