Complete Ramblings

Math in programming just generally sucks. I come from a mainly Java background, and recently I’ve been using Ruby. But in both cases, the statement holds true. I know this isn’t really a new problem, but for god’s sake, it’s 2007; why is it still a problem?

Using Ruby, let’s suppose we have a simple math problem… and we want to check equality:

1.2 + 1.0 == 2.2 (returns true)

Yay, it’s correct! But that’s not really much to ask of a language is it now. Let’s switch it up just a little bit:

1.2 - 1.0 == 0.2 (returns false)

Uhh… Ruby? You OK? I really don’t understand how this is acceptable. I know the argument that we generally work and think in a base10 system, while computers generally store numbers in binary, and there’s no exact way to store many numbers. But shouldn’t that be fixed (and by fixed, I mean an easy way provided for us to perform exact base10 math), assuming once again, we generally work in base10? i.e. when I subtract 1 from 1.2, shouldn’t I get exactly 0.2?
Anyway, if you do a little research, you’ll find that BigDecimal is supposedly much more accurate when performing calculations, so let’s try that:

require 'bigdecimal'
BigDecimal.new('1.2') - BigDecimal.new('1') ==
   BigDecimal.new('0.2') (returns true)

Yay, it worked! …but who wants to type ‘BigDecimal.new’ a thousand times? Dig a little further and you’ll find a BigDecimal utility, which adds functionality to other Ruby Numeric classes to convert them to BigDecimals:

require 'bigdecimal'
require 'bigdecimal/util'
1.2.to_d - 1.0.to_d == 0.2.to_d (returns true)

Still works, and it’s definitely cleaner, but remembering to append ‘.to_d’ may be somewhat of a pain (and unnecessarily ugly.) The innaccuracy of Float can still bite you, however; check this out:

require 'bigdecimal'
require 'bigdecimal/util'
x = 1.2000000000000000001.to_d
puts x.to_s('F') (prints 1.2)

Yep, our 1 in the 1/1000000000000000000th place at the end is lost. This is probably because BigDecimal is aware of the innaccuracy of Float, and since that was of such small value, it assumed it was just a precision issue and is dropped. Frustrating!

Another issue for us might be that using BigDecimal in place of Float probably has more overhead; I don’t personally have any benchmarks to compare the two. But, then again, I don’t really need them. For me, being precise far outweighs it being fast (to a point of course). If I was performing some super-intensive process, that did crazy math, and as a result I only needed an answer that was pretty close but not exact, I’d probably give Float a chance. But until then, it’s BigDecimal for me, despite it not being the easist/cleanest/prettiest solution.

At any rate, I can live (for now) with implementing BigDecimal in this way (or ‘new’ing them up when appropriate.) But if you happen to use ActionWebService in Rails, you have another problem. Currently (as of version 1.2.3), when you define your API, and use the :float datatype, you’ll find this does in fact use Float to convey numbers. Dig a little, and you’ll find that in their SVN repository they may be working on changing this to use BigDecimal instead. One can only hope!

A coworker and I attempted to dig in and try to convert it ourselves for use in a current project, but that attempt was fairly short-lived, and we instead use the “.to_d” method above to convert them to BigDecimals once inside the service method. This works for us, since we’re generally dealing with dollar amounts that aren’t terribly huge, so we’re only concerned with accuracy to the penny.

I fully intend, at some point, to revisit this issue and perhaps instead of replacing :float to use BigDecimal, using :decimal or :bigdecimal, thus leaving the ability to use Float if so desired. Hopefully by the time I get to it, they’ll release a new version with it already implemented. I can dream can’t I?