# Blog

## When 2 + 2 = 4.0001

If you use the imperial system to record weights in Roastmaster, and you roast in even measurements of, say 8oz, or 4oz, you may have noticed that as you near the end of your inventory for a particular bean, the number that Roastmaster displays as your inventory becomes a decimal that is very close to your actual inventory, but is sometimes off by hundredths of an oz (or a few grams).

What is happening?

Whenever your database is saved, the inventory in memory is being saved as gram integers to the database. This is effectively stripping off the decimal portions of a gram. Now, before you worry – a gram is roughly 6 beans, give or take – so it’s not serious, but it is definitely an annoyance that I plan to address in the next update.

Why is this happening?

Well, that takes a bit of explanation…

Computers are amazing things. In and of themselves, they are perfectly accurate machines – capable of crunching any number thrown at them. Unfortunately, though – storing those numbers in memory, or to a database, can be a problem.

Think back to the days of high school math, and everyone’s favorites… long division, and yes… fractions. Some are easy. For instance 1/4 = .25. Simple, right? Well, what about 1/3? .33 may come to mind, but the actual number is 0.33333333333333333… with the 3’s going on forever. That is the venerable repeating decimal – a number that can never be exactly represented in decimal notation. Now, once you’ve worked out about 4 or 5 decimal places, most of us (math teachers included) would say “close enough”. And that is exactly what computers have to do – otherwise those numbers would overflow all of the available RAM, and the extra precision wouldn’t do anyone any good.

So what does this have to do with coffee?

Well, Roastmaster users are located all over the world, and from what I know, the US is the last major holdout on the imperial measurement system. Yes… pounds and ounces – where nothing divides evenly, and conversions back and forth are impossible to do in your head, so we’ve added all of these auxiliary helper units like cups and pints. Our global friends though, using the metric system, are at an advantage here. Everything is even – everything converts – and computers have a much easier time working with it. Now – providing support for both at the same time is the dilemma that Roastmaster faces – every number ends up being a nasty looking decimal in the end when the imperial system is involved.

Unfortunately, SQLite databases in iOS are tricky when working with decimal numbers. The decimal number you save in is NOT guaranteed to be the number given back to you the next time you read the database. It will be close, but not always exact. The accuracy varies, but when dealing with larger numbers, it diminishes fairly quickly, so what starts out as accurate to the millionth place, can sometimes quickly dwindle to the point of only being accurate to the hundredth place.

I knew from the beginning of Roastmaster’s development there would always be tiny inventory drifts when roasting if the imperial system was involved, due to floating point decimal approximations. The design decision I faced in the very beginning was how to minimize this for the largest number of users. In the end, I opted to use the metric system internally for Roastmaster, and to store the inventory as gram integers. I thought this would yield the least overall drift, (and best precision) as it would eliminate the small inconsistencies that could creep in when dealing with decimals – especially for larger inventories like roasting shops would have.

I thought it was a good decision for a few reasons. One, I believe the metric system is superior to the Imperial system, and certainly easier to use. Two, I feel that even here in the states, for home coffee roasting, most people use metric as well – it offers more precision that trying to deal with quarters of an ounce. Even those that own roasters with half and quarter pound settings, usually whittle those numbers down to a lesser amount of grams until they find the sweet spot of the roaster. Three, shop roasters would have larger inventory and never notice, or care, about drifts of a fraction of a gram. Finally, and most importantly, the vast majority of the world are metric users, and would never even see an inventory drift at all, because that kind of thing just doesn’t occur in a system that converts evenly.

Now, as Roastmaster is being put through its paces, it turns out the drift for imperial users was a little more than I anticipated. In just 5 – 10 roasts, those gram fractions can add up quickly and amount to 1/10 to 3/10 of an oz, so users are left seeing, say, 15.86 oz of inventory instead of an even 16 oz.

What else does this affect in Roastmaster?

Absolutely nothing. All of Roastmaster’s internal calculations dealing with storage in the database operate on decimal numbers, and at much smaller amounts, which is safer for decimal precision. So, whatever number you put in for roasted weight, cupped weight or volume, or blended amounts, etc. is exactly the same number that is saved in the database – with all of its decimals intact. In addition, all of Roastmaster’s internal conversion algorithms operate with 6 decimal place accuracy, so this problem should only be seen in numbers that are reported directly from the transient inventory measurements.

If you’ve noticed this issue, I hope this has shed a little light on what is happening. Be on the lookout for a fix in the next update, and sorry if this has caused anyone trouble or confusion.

Cheers, Danny

Danny HallHome Coffee Roaster and App DeveloperView all posts by Danny Hall »

1. David BondySep 02, 2011

Is it possible for someone to send me the various database settings for a Behmor 1600. It is very hard to read the profile graphs in the manual and I guess someone has already done the work to enter it into their database. To save re-inventing the wheel can we have this type of data posted somewhere for all to share? TIA! David

• Danny HallSep 02, 2011

Hi David

Profile and program sharing is coming in the next update, but there’s no way to import and export that at the moment.

Just emulate the profiles and programs on the Behmor. P1, P2 etc. for Profiles and A, B etc. for Programs. These will be the values you choose for roasts. I’ve almost finished the coding for full-blown native Behmor curves – this will be in the upcoming update – and all of the math and time shifts will happen automatically. But, since Behmor heat settings rely on an algorithm of profile, program and weight settings all at the same time, the new Behmor curves in Roastmaster will operate on a per roast basis. Otherwise you’d end up with a mess of profiles and programs – 1 for every possible combination – 54 I think in all (some combinations aren’t valid). I think you’ll find the upcoming solution elegant and easy to use, and let you visualize all of the Behmor heat settings in the graph, as you time shift to match past roasts. Plus its going to work well for profile and programs (and snapshots) if you do choose to break them out into items to match certain combinations. For now, though I’d stick with the standard 5 profiles and 5 programs. When the update comes out, you can create snapshots of profiles containing your favorite Behmor curves. For now, though, it doesn’t gain you anything.

I’m also going to try and squeeze in a new data type for roasters – auxiliary settings. This will let you hold references for the weight settings you roast with. The next update in some ways is Behmor-centric, though there’s a lot of other cool things coming. Label printing, import and export, DropBox support to name a few.

Any questions, just let me know, but this is the way I have my own database setup for my Behmor.

Cheers
Danny

2. ginnyMay 17, 2012

I found it.