Ruby on Rails

Colin Law wrote in post #970648:
> On 25 December 2010 14:24, Marnen Laibow-Koser <lists@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
marnen@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-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.