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.
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?
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…
Am Dienstag, 17. Jul 2007, 14:50:18 +0900 schrieb Robert B.:
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
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…
irb(main):002:0> a = 5.123
One way I guess would work is to make sure all args in the calculation
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
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.
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::PI.big * 2.0
=> 6.283185307178
irb > Math::PI.big * 2.0.big
=> #<BigDecimal:81c2b88,‘0.6283185307 17958E1’,20(36)>
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.
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.
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.
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.
It would take me too much time ATM to do it and it should also be
checked whether changing #coerce causes issues somewhere else…
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
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::PI
r=f.cont_fract_appr
p ‘the continued fraction approximation (to precision 10**-8 is)’
p r
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.