ciao a tutti (hi to hall)
I just discoverd a gem to have arbitrary precision numbers and want to
share with the forum.
Install the gem with
gem install flt
an example script follows; it computes the square root of 2
require ‘flt’
include Flt
DecNum.context.precision = 200
p DecNum(2).sqrt
produces:
DecNum(‘1.4142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727350138462309122970249248360558507372126441214970999358314132226659275055927557999505011527820605715’)
documentation here
http://flt.rubyforge.org/
hope this helps
DecNum.context.precision = 200
p DecNum(2).sqrt
produces:
DecNum(‘1.4142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727350138462309122970249248360558507372126441214970999358314132226659275055927557999505011527820605715’)
Cool.
I think you can do something similar with the builtin BigDecimal class
require ‘bigdecimal’
BigDecimal.new(“2”).sqrt(200)
=> #<BigDecimal:3076900,‘0.1414213562 3730950488 0168872420 9698078569
6718753769 4807317667 9737990732 4784621070 3885038753 4327641572
7350138462 3091229702 4924836055 8507372126 4412149709 9935831413
2226659275 0559275579 9950501152 7820605714 7010955997
1605970125E1’,224(224)>
Of course, that’s decimal, so flt might be more precise.
-rp
On 04/28/2010 11:31 AM, Giampiero Z. wrote:
documentation here
http://flt.rubyforge.org/
What’s the difference (precision? performance?) vs. doing
irb(main):001:0> require ‘bigdecimal’
=> true
irb(main):002:0> BigDecimal(“2”).sqrt(200).to_s
=>
“0.1414213562373095048801688724209698078569671875376948073176679737990732478462107038850387534327641572735013846230912297024924836055850737212644121497099935831413222665927505592755799950501152782060571470109559971605970125E1”
irb(main):003:0> BigDecimal(“2”).sqrt(200)
=> #<BigDecimal:93215a4,‘0.1414213562 3730950488 0168872420 9698078569
6718753769 4807317667 9737990732 4784621070 3885038753 4327641572
7350138462 3091229702 4924836055 8507372126 4412149709 9935831413
2226659275 0559275579 9950501152 7820605714 7010955997
1605970125E1’,224(224)>
irb(main):004:0>
?
Kind regards
robert
2010/4/29 Giampiero Z. [email protected]:
=> #<BigDecimal:93215a4,'0.1414213562 3730950488 0168872420 9698078569
sorry for my ignorance
No problem. Maybe the gem you’ve found is a nice wrapper around
BigDecimal with better #inspect and #to_s. In any case I thought it
good to know that the standard lib contains something similar. 
Kind regards
robert
Robert K. wrote:
What’s the difference (precision? performance?) vs. doing
irb(main):001:0> require ‘bigdecimal’
=> true
irb(main):002:0> BigDecimal(“2”).sqrt(200).to_s
=>
“0.1414213562373095048801688724209698078569671875376948073176679737990732478462107038850387534327641572735013846230912297024924836055850737212644121497099935831413222665927505592755799950501152782060571470109559971605970125E1”
irb(main):003:0> BigDecimal(“2”).sqrt(200)
=> #<BigDecimal:93215a4,‘0.1414213562 3730950488 0168872420 9698078569
6718753769 4807317667 9737990732 4784621070 3885038753 4327641572
7350138462 3091229702 4924836055 8507372126 4412149709 9935831413
2226659275 0559275579 9950501152 7820605714 7010955997
1605970125E1’,224(224)>
irb(main):004:0>
?
Kind regards
robert
maybe no difference ?
I didn’t know of BigDecimal neither
sorry for my ignorance
you can find the section
DecNum vs BigDecimal
at the bottom of the documentation page
http://flt.rubyforge.org/
DecNum solves some of the difficulties of using BigDecimal.
One of the major problems with BigDecimal is that it‘s not easy to
control the number of significant digits of the results. While addition,
subtraction and multiplication are exact (unless a limit is used),
divisions will need to be passed precision explicitly or else an
indeterminate number of significant digits will be lost. Part of the
problem is that numbers don‘t keep track of its precision (0.1000 is not
distinguishable from 0.1.)
…
Robert K. wrote:
an example script follows; it computes the square root of 2
DecNum(‘1.4142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727350138462309122970249248360558507372126441214970999358314132226659275055927557999505011527820605715’)
=>
?
Kind regards
robert
If my reading of the documentation is correct the difference is how the
intermediate results are stored. Dividing 1 by 3 with a precision of 2
would result in 0.33 versus 0.3333333… If you print a commission rate
of 33.33% on a form and a charge of $5,0000, you want the amount to show
$1,666.50 (5000 * .3333), not $1,666.67 (5,0000 * 1/3) as a lot of
people will complain that your figures are wrong.
I use fixed precision for all my work as it deals with money and
everything has to match to the penny.