Force calculation result to BigDecimal

[Robert Brown]

Hi all,

I'm doing some complex math which I need to be based on BigDecimal
accuracy (not Float). It seems that ruby defaults to Float when there's
a mixture of type in there, e.g.

Code :

1. irb(main):001:0> require 'bigdecimal'
2. => true
3. irb(main):002:0> a = 5.123
4. => 5.123
5. irb(main):003:0> b = BigDecimal("6.789")
6. => #<BigDecimal:8b4c0,'0.6789E1',8(8)>
7. irb(main):004:0> c = a * b
8. => 34.780047
9. irb(main):005:0> c.class
10. => Float

Is there a way I can force a BigDecimal outcome.

One way I guess would work is to make sure all args in the calculation
are BigDecimal, but that's a bit tiresome. For a start, I'd have to
type check each arg and convert to BigDecimal if it was not BigDecimal -
that's gotta be slow...

On a related note, how do I initalize a BigDecimal from a Float (without
converting to string first). How could I extend BigDecimal for this?


Thanks,



Rob

 

[Todd Benson]

Hi all,

I'm doing some complex math which I need to be based on BigDecimal
accuracy (not Float). It seems that ruby defaults to Float when there's
a mixture of type in there, e.g.

Code :

1. irb(main):001:0> require 'bigdecimal'
2. => true
3. irb(main):002:0> a = 5.123
4. => 5.123
5. irb(main):003:0> b = BigDecimal("6.789")
6. => #<BigDecimal:8b4c0,'0.6789E1',8(8)>
7. irb(main):004:0> c = a * b
8. => 34.780047
9. irb(main):005:0> c.class
10. => Float

Is there a way I can force a BigDecimal outcome.

One way I guess would work is to make sure all args in the calculation
are BigDecimal, but that's a bit tiresome. For a start, I'd have to
type check each arg and convert to BigDecimal if it was not BigDecimal -
that's gotta be slow...

On a related note, how do I initalize a BigDecimal from a Float (without
converting to string first). How could I extend BigDecimal for this?


Thanks,



Rob

Here's a quick fix. There may be a better way to handle this, though.
Again, I'll give the usual warning about modifying core classes: you
shouldn't normally do it unless you can be certain it won't break
yours or anyone else's code.

class Float
require 'bigdecimal'
def big
BigDecimal self.to_s
end
end

p pi = Math:I.big
# prints out something like
# #<BigDecimal:2df3ffc,'0.3141592653 58979E1',20(20))
p "\n"

p pi * 2.0.big
# prints out something like
# #<BigDecimal:2deb35c,'0.6283185307 17958E1',20(36))
p "\n"

Todd

 

[Robert Brown]

Here's a quick fix. There may be a better way to handle this, though.
Again, I'll give the usual warning about modifying core classes: you
shouldn't normally do it unless you can be certain it won't break
yours or anyone else's code.

Thanks Todd...

What are the risks in modifying core classes? I've already done this a
little by adding .round(n) to BigDecimal, where n is the decimal places.

Appreciate your tip, but I was thinking the other way round: have
BigDecimal take Float as an initializer, not have Float output
BigDecimal.

But this is all by-the-by. What I'm really looking for is BigDecimal
math, not Float, in my calculations (when there's a mixture of
BigDecimal, Float and Fixnum types).

Still looking for suggestions on how I can do this better than manual
type-checking and casting...


Thanks,

 

[Bertram Scharpf]

Hi,

Am Dienstag, 17. Jul 2007, 14:50:18 +0900 schrieb Robert Brown:

Appreciate your tip, but I was thinking the other way round: have
BigDecimal take Float as an initializer, not have Float output
BigDecimal.

-From time to time I wonder why there is no BigDecimal
initializer taking a Float argument. There seems to be a
point as Float values aren't unambiguous and you have to
explicitly mention which one you mean of

"%f" % 1.8 # => "1.800000"
"%32.24f" % 1.8 # => " 1.800000000000000044408921"

So I'd rather say it's disencouraged to convert Float to
BigDecimal.

Bertram

 

[Robert Klemme]

Here's a quick fix. There may be a better way to handle this, though.

Hm.... I don't think this is a fix because once you have a float you
lost all the precision. A better fix is probably to change #coerce to
work properly. Another solution is to make sure all values are
converted to BD before starting the calculation.

Note, that BigDecimal is returned when working with integers.

Again, I'll give the usual warning about modifying core classes: you
shouldn't normally do it unless you can be certain it won't break
yours or anyone else's code.

Very good point!

Kind regards

robert

 

[Robert Brown]

So I'd rather say it's disencouraged to convert Float to
BigDecimal.

Indeed! I'd rather not use Float at all in this project as it's
financial math and float quirks will cause me problems. I'd be prepared
to take the performance hit and just turn off Float if I could...

 

[Todd Benson]

Hm.... I don't think this is a fix because once you have a float you
lost all the precision.

Can you elaborate on this? I was under the impression that converting
to BigDecimal before arithmetic operations would get around this.
Using
class Float
def big; BigDecimal(self.to_s); end
end
irb > Math:I.big * 2.0
=> 6.283185307178
irb > Math:I.big * 2.0.big

A better fix is probably to change #coerce to
work properly. Another solution is to make sure all values are
converted to BD before starting the calculation.

This would be the best solution (maybe through #induced_from?), but I
don't know how to do it.

Note, that BigDecimal is returned when working with integers.

Todd

 

[Axel Etzold]

Dear Robert,

Indeed! I'd rather not use Float at all in this project as it's
financial math and float quirks will cause me problems. I'd be prepared
to take the performance hit and just turn off Float if I could...

you could use a "continued fractions" approximation

http://mathworld.wolfram.com/ContinuedFraction.html

to your Float number and then work with fractions without
any further loss in accuracy. Continued fractions are in a sense the
best possible approximations to irrational numbers
(and of course to rational numbers, the latter being
fractions themselves).

Once you have a fraction (use the code below to get it
from a continued fraction), you can calculate with it in Ruby
using Rational:

require "rational"
a=Rational(1,2)
b=Rational(3,4)
p a+b # => Rational (5,4) , as 5/4 == 1/2+3/4
p (a+b).to_f # => 1.25

Below is some code to give you the continued fraction representation
(4) in the webpage cited above.

From the continued fraction representation, you can obtain the
partial quotients mentioned in (11) of the cited webpage by the method cont_fract_to_fract below.


Best regards,

Axel


----------------
class Float
def cont_fract_appr(*prec)
a=[self.floor]
t=[self-self.floor]
res=[]
if prec==[]
prec=10**-8
else
prec=prec[0]
end
k=1
rem=t[-1]
while rem.abs>prec
r_new=1/t[-1]
if (r_new+prec).floor>r_new.floor
r_new=r_new+prec
end
a[k]=r_new.floor
t[k]=r_new-r_new.floor
k=k+1
p,q=(a.cont_fract_to_fract)
rem=(self-p[-1].to_f/q[-1].to_f).abs
end
return a
end
end

class Array
def cont_fract_to_fract
# produce the partial fractions (see eq. 11 of webpage)
p=[0,1]
q=[1,0]
for n in 2..self.length+1
p<<self[n-2]*p[-1]+p[-2]
q<<self[n-2]*q[-1]+q[-2]
end
return p,q
end
end
# usage example:


f=Math:I
r=f.cont_fract_appr
p 'the continued fraction approximation (to precision 10**-8 is)'
p r

 

[Robert Klemme]

Can you elaborate on this? I was under the impression that converting
to BigDecimal before arithmetic operations would get around this.

Actually you are right. I somehow thought you intended #big to be
called on the result, i.e. after the calculation. Stupid me. Sorry
for the confusion.

Using
class Float
def big; BigDecimal(self.to_s); end
end
irb > Math:I.big * 2.0
=> 6.283185307178
irb > Math:I.big * 2.0.big


This would be the best solution (maybe through #induced_from?), but I
don't know how to do it.

It would take me too much time ATM to do it and it should also be
checked whether changing #coerce causes issues somewhere else...

Kind regards

robert