Monday, May 23, 2011

Rounding to significant digits in Ruby

A few years ago, I built a Rails application which estimated the nutritional information of entire recipes by mapping the individual ingredients to food records in the USDA nutritional database, then summing up the nutritional values across all the foods.

This is a surprisingly tricky task. In many cases there's a lot of hand-waving involved. How much meat do you get from an 8 pound turkey? How do you calculate the amount of food consumed versus the amount measured before cooking? What if the USDA only measured the nutrients for a raw sample, but you eat it cooked?

Clearly, many of these nutritional values are going to be ballpark figures, so it wouldn't make sense to display them out to the tenth decimal place. But that's what you'd get by default after doing floating-point multiplication and division: A lot of spurious digits.

Why not just round everything to, say, two decimal places, and display that? As an example, consider that one set of nutritional info may work out to contain 548.667 calories and 0.384503 mg of vitamin B6. A fractional calorie is just noise; nobody is going to worry about whether their lunch has an extra 2/3 of a calorie, even if the number is accurate. But 0.38 mg of B6 is about a quarter of the daily allowance; we can't afford to ignore those fractional milligrams.

This is where significant figures AKA significant digits come in. I only want to preserve the digits furthest to the left -- the most significant -- regardless of the location of the decimal point. I searched for a way to do this in Ruby, but rather than finding a solution, I found that many people confuse rounding to N significant digits with rounding to N decimal places. These are not the same thing.

548.667 rounded to 2 decimal places is 548.67
548.667 rounded to 2 significant digits is 550.0

So how can this be done without converting the number to a string and scanning it? Scientific notation. This notation expresses a number in terms of a fixed-point number and an exponent, and is actually similar to the way floating point numbers are represented internally. sprintf can write this format, and to_f can read it. Because normalized scientific notation always places exactly one digit to the left of the decimal point, specifying a precision of N-1 in sprintf's format string will round a number to N significant digits. A format of "%.1e" will give us 2 significant digits.

irb(main):001:0> a = 548.667
=> 548.667
irb(main):002:0> b = sprintf("%.1e", a)
=> "5.5e+02"
irb(main):003:0> b.class
=> String
irb(main):004:0> c = b.to_f
=> 550.0
This does what I want it to, so why not add a method to Float?

irb(main):006:0* class Float
irb(main):007:1>   def sigfig(digits)
irb(main):008:2>     sprintf("%.#{digits - 1}e", self).to_f
irb(main):009:2>   end
irb(main):010:1> end
=> nil
irb(main):011:0> a.sigfig(2)
=> 550.0
irb(main):012:0> d = 0.38450
=> 0.3845
irb(main):013:0> d.sigfig(2)
=> 0.38 

That works. But for the purpose of display, I'd really like to suppress the trailing decimal point and zero when the number has been rounded to an integer. The precision of the number 550 isn't clear (it could be ones or tens), but displaying it as 550.0 implies more precision than we have. I'll create a method which is designed specifically for output.

irb(main):001:0> a = 548.667
=> 548.667
irb(main):002:0> class Float
irb(main):003:1>   def sigfig_to_s(digits)
irb(main):004:2>     f = sprintf("%.#{digits - 1}e", self).to_f
irb(main):005:2>     i = f.to_i
irb(main):006:2>     (i == f ? i : f).to_s
irb(main):007:2>   end
irb(main):008:1> end
=> nil
irb(main):009:0> a.sigfig_to_s(2)
=> "550"

There's probably a better way to do this; I still tend to speak Ruby with a C accent and I may have missed a shortcut. But it does achieve my goal of reasonably clean output for tables full of Floats. Here's a page snippet from one of the sites which uses this code.

Sunday, May 22, 2011

Firefox Moiré hack (CSS abuse)

Here's a code snippet that's been sitting on my hard drive since last January. It generates Moiré interference patterns via the CSS -moz-repeating-radial-gradient property.  I find this interesting in that even a small PNG created this way requires about 1000x the storage as the code used to generate it.

The hack only works in Firefox; IE does not support repeating-radial-gradient and Webkit's -webkit-repeating-radial-gradient does not attempt to render the gradients with the subpixel (im)precision required for the effect. In Firefox, simply resizing the browser window in either dimension will change the way this is rendered, and scrolling the page will probably cause it to glitch. Try it!


Here's a screencap from Firefox, which is pretty much guaranteed not to look exactly like the above...even if you're viewing this in Firefox.


The code contains several magic numbers which were selected just to make this look funky.

<div style="height: 500px; overflow: hidden; position: absolute; width: 500px;">
<div style="background: -moz-repeating-radial-gradient(red, red 2px, blue 2px, blue 3px); height: 800px; position: absolute; top: -200px; width: 800px;">
<div style="background: -moz-repeating-radial-gradient(black, black 1px, transparent 1px, transparent 2px); height: 850px; left: -150px; position: absolute; top: 100px; width: 830px;">
</div>
</div>
</div>

You can also fill the entire viewport with pretty interference patterns using a tiny HTML document. Resize the browser for eye candy. Endless fun for the whole family!

<!DOCTYPE html><html><head><title>Moire</title></head>
<body>
<div style="background: -moz-repeating-radial-gradient(black, black 1px, transparent 1px, transparent 2px); position: absolute; top: 0; left: 0; width: 100%; height: 100%">
</div>
</body>
</html>

Warning: Applying the gradient directly to the body element may cause Firefox to hang and eat a ton of memory. It looks like a bug was filed on this over a year ago with priority "critical", but it's still open. So...don't do that.