# Estimating Goodly – or, Visualizing Numbers

The ability to estimate accurately (an oxymoron, I know) is an invaluable tool in chocolate and in life.

I was lucky to have been introduced to the metric system at a fairly young age, as this necessitated my being able to fluently translate between two different measurement systems. Ultimately, I ended up choosing to use the metric system for most everything as it just makes the maths so much easier. My weather, maps, and other apps are all set to metric measurements

But, as I live in the US, most everything is *not* in metric so I had to figure out ways to make it easy to move back and forth between the two systems. This required me to discover shortcuts.

**The Value of Estimating Accurately**

When it comes comes down to it, in daily life in the real world, precision when it comes to numbers is, for most of us, only a concern when it comes to money. Accuracy in measuring is important in some areas – baking is one that comes to mind – because chemistry is involved. Accuracy in measuring is also important when building things – from the smallest transistor to the largest skyscrapers.

But, for most of us, most of the time, being able to get to about the right answer – even knowing that an answer is the correct order of magnitude – is good enough. The precise answer might be 98, but an estimate of 100 is good enough for most purposes.

To a large extent, IMO, this is a problem of an educational system that focuses on getting precisely correct answers in all situations, and that anything but the precisely correct answer is not just an error, it’s wrong or bad.

In this undertaking I was aided and abetted by my father, who had a BS in Maths from Reed College and an MS in Maths from Yale. He encouraged me from a young age to develop an intuitive sense for the magnitude of the answers to numerical problems in my head – if I needed a precise answer I could use a computer or calculator. I was also encouraged to understand underlying concepts rather than memorize equations – I could always refer to a book if I needed to know how to apply a specific equation or theorem.

**Estimating Temperature**

Working with temperature is the first place where I started working regularly with two measurement systems – Centigrade and Fahrenheit. I won’t go into the differences in the bases of these two systems, rather I will talk about the insight that lead to the shortcuts I use today when working with temperatures.

In photographic chemistry, the temperature for B&W is 68ºF or 20ºC. The temperature for color is 86ºF or 30ºC.

What this means is that:

```
10C is equivalent to 18 (86-68) degrees F.
So, 5C is 9F.
1C is 1.8F or – close enough for many uses – 2F.
40C is 30C + 10C which is 86+18 or 104F
50C is 30C + (2*10C) or 86+36 or 122F
15C is 20C (68F) – 5C (9F) or 57F
```

It turns out, that for almost everything I want to do with chocolate – or the weather *most* days – my knowing that 20 and 30C are 18F apart (and 68F and 86F respectively) and that by calculating common factors (1 and 5) make conversion between the two systems without a calculator really easy. For me.

You don’t have to adopt my system, which is based on my experience in wet chemistry photography – for many years I had a tactile, visceral, sense of what 68 and 86F *felt* like because I had my fingers in liquids at those temperatures on a daily basis. You can figure out one that makes the most internal, intrinsic, sense, *to you.*

**Note**

Terms like kilo, mega, and giga are binary terms. One thousand is not the same as one kilo, as kilo = 2^10 or 1024. For the purposes of estimating distances and volumes and time and the like in this post, I am going to use 100, 1.000, 1o,000, etc, not their binary equivalents because, *after all, we are just estimating*.

**Estimating Distance**

As a teenager I was a competitive swimmer and found I had to deal with the difference between short-course races (measured in yards in my local high school training pool) and long-course races (measured in meters in the local olympic pool). So, the 100Y butterfly versus the 100M butterfly.

A meter is ~39.36 inches. 3.36 inches is really close to 10% of 36 inches, so it’s easy for me to estimate that 100M is about 1__ 1__0Y just by remembering this one factor: 10%. It’s not exact, but it’s close enough for most everything I need to do on a daily basis.

Similarly, one mile is close to 1.6 kilometers (1.609 is a more precise number). That means a kilometer is the inverse (1/1.6) or 0.6 miles. So, 100 km is pretty close to 60 miles, 100 miles is pretty close to 160km.

Extending the temperature example, five miles is *about* eight km (by extension 50 and 80), ten km is *about* six miles; one mile is *about* 1.5 km, two km is *about* 1.2 miles. Again, the conversions are not precise – for that I can use a calculator or converter app.

The approach, for me, is to think about larger quantities in terms of 1/2 (50%), 1/4, (25%) 1/10 (10%), and 1/20 (5%) and use addition and subtraction rather than multiplication and division.

*What I want to do is develop is an intuitive feeling for the magnitude of the result.* Among other things will help me get a feeling if the answer is in the ballpark or is the right order of magnitude (the same power of 10, or “on the order of”).

**Estimating Volume**

Many years ago (this was back in the late 1980s early 1990s) I started thinking about writing a book on this topic I thought of as *Visualizing the Magnitude of Large Numbers*.

My inspiration for this book was trying to communicate around how big kilobytes, megabytes, gigabytes, and terabytes were. The context was an article about how large a hard disk array would need to be to store a library of ‘n’ movies. At the time, hard disks were big things and not very dense so I asked, “What if it took a hard disk the size of a shoe box to store one movie, what does that mean for an on-demand video streaming service? How big is 1000 shoe boxes (1000 movies)?”

The reason I chose shoe boxes is that everyone has an idea of about how big a shoebox is.

Of course, today, I can easily cram more than 100 TB of hard disk into that same volume. But that was then.

But that doesn’t really do a good job of helping us understand what a kilo (thousand), million (mega), or billion (tera) * looks* like.

So I cast around for examples and decided on a sugar cube, giving it a dimension of 1 cm (10mm or about .4 inches) on a side – just to make the math easy because not all sugar cubes are actually that size.

To visualize the number 100, arrange 100 sugar cubes in a single-layer 10*10 array. This is ten cm or about four inches on a side. To visualize the number 1,000 add nine layers on top of the first one, resulting in a cube of 1000 sugar cubes that is about four inches on a side. It turns out this is an easy way to visualize the number 1000 in concrete (or at least *sugarcrete*) terms. 100o sugar cubes is a cube about four inches or ten centimeters on a side.

One million is 1000 times 1000. To get to one million from one thousand, I do the same thing I did to get to 1000 from 100 in all three dimensions – I extend the base layer to 100 by 100 sugar cubes and then create a stack of 100 layers. 100 times 100 times 100 equals one million. This means that a cube of one million sugar cubes is about 40 inches on a side. But wait! Remember that one meter is 39.36 inches and we can easily visualize a cube of one million sugar cubes that is *about* one meter on a side, or one cubic meter.

The great thing about this is recognizing the existence of a pattern: one billion (giga) is 1000 times 1000 times 1000. I just extend what I did to get from kilo (thousands) to mega (millions) to get to billions – I extend the base to 1000 sugar cubes on a side because 1000*1000*1000 is a billion. 400 inches is about 10 meters. So a gigabite of sugar cubes (assuming one sugar cube is one bite) is about 10 meters, or 33 feet, on a side.

We’ll see the number 33 show up in the next section. I believe it’s a coincidence, but it’s possible there’s some underlying connection – I have not explored it.

**Estimating Time**

Quick – how many days is a megasecond? Though we all regularly cycle through one million seconds, few of us have any sense of how many days are in one million seconds.

Part of the reason why is that time uses inconvenient factors – 60 seconds in a minutes, 60 minutes in an hour, 24 hours in a day, so the number of seconds in a day is 60*60*24.

Working that out in my head that’s 3,600 (6*6*100) seconds in an hour. 10 hours is 36,000 seconds. 24 hours is 36,000+36,000+(4*3600) or 72,000+14,400 or 86,400. Ten days is 864,000 seconds, which us about 14% less than one million.

So, one million seconds is *about* 11.15 days.

Another way to think about this, if it makes it easier for you, is to realize that 60 is 20% greater than 50 (50+(2*5) and 24 is 20% greater than 20. So you can use 50*50*20 and add 2o% to each term to arrive at a more precise answer.

Okay, quick: how long is a gigasecond? Before you start to calculate, remember that one billion is 1000 times larger than one million. The answer is 11.15*1000 or 11,150 days. But how many years is one billion seconds? A year is 365 days, and 365 is about 10% less than 400. Because 11,150 has a *reasonably* close (for estimation purposes) multiple (12,000) to 400, one billion seconds is about 30 years + 10% years, or *about* 33 years.

There’s that 33 I mentioned at the end of the previous section. Coincidence?

How long is a terasecond? It’s about 1000*33 or about 33 millennia.

**Conclusion**

The ability for me to arrive at an approximate answer quickly, in my head without needing a calculator, is an *invaluable* skill in my chocolate consulting work and in other parts of my life. While I may not use it daily, I do rely on it regularly.

Another estimation tool I use is the number of states in the US – 50. I was once asked about the number of photographic images (pre-digital cameras and camera phones) – negatives and positives – processed in a year. I don’t remember the number given to me to assess, but let’s assume one billion. What does it take to get to one billion? 1,000,000/50 is 20,000,000. What that means is that, on average, twenty million images were processed every year in each state in the US. Now, there will be fewer in Montana and Hawaii than in New York, but we’re just looking for plausibility/order of magnitude here.

Now divide twenty million by the number of days per year. One way to think about the number of days in a year is that it’s about 365+10% or 400. 400 into twenty million is 50,000 then add 10%, or 55,000. So – does it seem plausible that an average of 55,000 photos were taken on film each and every day in each US state? It’s not *im*plausible.

We can cross-check the number using the population of the United States. Let’s say it’s 300 million. That one billion photos is a bit more than three photos per person per year – which is probably *way* too low. But what we’ve done is used two different calculations to evaluate the proposed number and found it within the bounds of reason and likely undercounting. I know that my personal photo work at the time probably led me to be taking at least one 36-exposure roll of film, on average, once per month, and when I was assisting professional architectural and studio photographers the number could easily reach hundreds of exposures in a single day, so one billion images/year – as big as that number seems – is likely outside the lowest bounds of an actual count.

This is why having some personal experience or relating a calculation to a personal experience – in my case photography – can make the results of estimating more tangible and real.

**Other Estimation Resources**

Featured image credit: Matt Walsh on Unsplash