FermCalc Javascript page produces incorrect answers

[winemaker81]

In the Finer Wine Kits thread:

just curious -- which ABV calc method do you tend to use?

In answering, I compared my calculation against the FermCalc Javascript page, and found a few problems. This topic is worth exploring on its own.

My answer to Bmd2k1's question is that I use the following formula. I created an worksheet function in Excel, which round the answer to 3 decimal places, which Excel displays as a decimal.

ABV = (InitialGravity - FinalGravity) / 7.36 * 10

For OG = 1.100 and FG = 0.994, this produces 14.4%.

Using the Javascript FermCalc page, I get:

14.5% Berry
14.4% Duncan & Acton
14.1% Balling
14.6% Cutaia, Reid, & Speers

I checked FermCalc's formula description -- the formula I use is Berry, which they list as: av = (sgi – sgf) / 0.00736. In English, sgi = InitialGravity, sgf = FinalGravity

This formula produces the same answer as the one I use, the difference is the decimal place is in a different location. I verified FermCalc's formula in a calculator, to ensure the results are not affected by Excel or Javascript. This produces 14.40217391304348, which rounds to 14.4%.

However, FermCalc's Javascript page produces the wrong answer, 14.5%.

Since I found one error, I checked Duncan & Acton. This is more complicated, as it requires 3 formulas, as the results of #1 are used in #2, and the results of #2 are used in #3:

sgc = sgi – 0.007
F = 7.75 – 3000(sgc – 1.0) / 800
av = 1000(sgi – sgf) / F

Executed in Excel for the above values, I get 14.3. Instead of being high like Berry, this one is low.

Ok, on to the next 2. Balling and Cutaia are not wine formulas, they are beer formulas. I've read in numerous places that different formulas are required for different ABV ranges, as the curve is not an even one. Beer formulas (ABV in the 4% to 8% range) are supposed to be different from the wine ranges. This may explain why these two produce low and high results, respectively.

At this point, I have no trust in FermCalc, as the Javascript calculators produce wrong answers. This is very sloppy programming.

 

[salcoco]

even the government allows a 1.5% deviance in displaying there abv on labels. Maybe I will contemplate your problem once I have a glass of wine.

 

[cmason1957]

I thought the Federal Government only allowed a +/- 0.5% deviation. I have trouble getting very upset over if Fermcalc (or any tool) is off, since all of them are just approximations anyway. And I can't promise I read the SG at either end correctly down to 1.095, might be anywhere from 1.097- 1.093. It's all noise to me.

 

[winemaker81]

What does labeling as per the US TTB have to do with a private web site publishing incorrect formulas?

Neither of you care, but a lot of folks do and they rely on FermCalc. These formulas are not exactly rocket surgery, and are easily programmed in Excel in 2 minutes. If FermCalc can't do that right, why trust anything they publish?

Out of curiosity I searched and found the following on the US TTB site:

Alcohol content may be stated as a specific percentage with a tolerance of:

• Plus or minus 1 percentage point for wines containing over 14% alcohol by volume;

Example: A wine is labeled with the alcohol content statement “18% ALC. BY VOL.” Provided the actual alcohol content does not exceed 19% or fall below 17%, the label alcohol content statement “18% ALC. BY VOL.” is permissible.

• Plus or minus 1.5 percentage points for wines containing 14% or less alcohol by volume;

Example: A wine is labeled with the alcohol content statement “12% ALC. BY VOL.” Provided the actual alcohol content does not exceed 13.5% or fall below 10.5%, the label alcohol content statement “12% ALC. BY VOL.” is permissible.

Alternatively, alcohol content may be stated as a range. The range may not exceed:

• 2 percentage points for wines containing over 14% alcohol by volume;

Example: “17%-19% ALC. BY VOL.”

• 3 percentage points for wines containing 14% or less alcohol by volume;

Example: “9%-12% ALC. BY VOL.”

TTBGov - Wine Labeling: Alcohol Content

 

[cmason1957]

I guess my point is, those formulas are at best approximations and depend on how well you can read the exact SG both at the start and at the end. The example you give is well within the expected error band of all of that taken together.

I seldom worry about the ABV. For me, it just doesn't matter.

 

[balatonwine]

First step: Let us all get on the same page. What FermCalc page are you using. I get this:

 

[cmason1957]

My guess is this is the page in question:



One thing I did notice on this page is by adjusting the Calibration temperature down to 60F, which I believe is what my hydrometers are calibrated to and the measurement temp to 68 F. I did get different values. I somewhat knew that I would. Maybe that is where the difference is coming in that Bryan is seeing

 

[balatonwine]

What does labeling as per the US TTB have to do with a private web site publishing incorrect formulas?

I deal with analytical data analysis, and I think we need to take a time out.

You have not proven that a web site has published incorrect formulas. And I noticed many areas where you are not considering basic issues like significant figures (14.40217391304348... seriously????), or seem to fully understand how software in general deals with floating point numbers (it does it poorly). I have an IT company, specializing in data analysis and statistics, and most laymen get this concept wrong. For example, Excel does not properly handle significant figures well. Telling Excel to limit a number to some decimal point is often only a display issue, and has nothing to do with significant digits. I knew a statistician who for years tried to tell Microsoft that Excel was calculating their stats wrong, but MS never changed Excel.... Just saying... I do not trust Excel. Nor a calculator. They both suffer from floating point error. Thus saying one web site is in error is.... well problematic. I agree there is a lot of lousy programming out there. But using one possibly incorrect software to judge another maybe incorrect software is pointless and fundamentally counter productive.

In short.... It is complicated. Suggestion: avoid making declarative statements about one web site or software. Post results and full data used to get those results, and rather postulating a query how to best estimate something, then back it up with empirical data.

Hope this helps.

 

[balatonwine]

One thing I did notice on this page is by adjusting the Calibration temperature down to 60F, which I believe is what my hydrometers are calibrated to and the measurement temp to 68 F. I did get different values. I somewhat knew that I would. Maybe that is where the difference is coming in that Bryan is seeing

Well stated. As I often say... The issue is complicated. And thus, IMHO, one should avoid stating a web page gives "incorrect" answers. Because, well... it is complicated. Full disclosure of all original input data is needed for anyone here to really evaluate the issue.

 

[G259]

The wine I'm having right now is really good!
I'm sure that the wine that I have tomorrow
will be good too, or is that too simple!

 

[balatonwine]

Minor comment:

I looked at FermCalc's Javascript on a very limited basis. And they are using the Javascript function "toFixed" in their code. This is a good sign. "toFixed", can deal with significant digits properly. If their formulas do this properly or not I can not confirm, because web page JS is often compressed and obfuscated, but the fact they use toFixed is a good sign.

So, to compare FermCalc with Excel, one may need to use a far more complicated formula than expected in Excel... (because from a real mathematical reality, Excel kind of sucks).

https://exceljet.net/formula/round-a-number-to-n-significant-digits

 

[winemaker81]

The page in question is: Hydrometer SG Drop Calculator

You have not proven that a web site has published incorrect formulas.

I'm an IT professional with extensive experience in dealing with the errors produced using real numbers. But you're correct -- their formula is an acknowledged one, their published formula is not wrong. Their implementation is incorrect.

I took FermCalc's published formula, which is essentially the same as the one I use (result's decimal in different place), and calculated it numerous ways, including Excel, Window's calculator, my phone's calculator, and a desk calculator (I have one shaped liked a 3.5" floppy disk from MacWarehouse I've carried for 30+ years). All produce the same result to 5+ decimal places. We only need 3 places, e.g., 0.144 = 14.4%, so the overall precision exceeds the need.

Among my other professional skills is quality assurance, AKA testing, and having worked in several financial environments, accuracy is a pass/fail situation. FermCalc fails.

I guess my point is, those formulas are at best approximations and depend on how well you can read the exact SG both at the start and at the end. The example you give is well within the expected error band of all of that taken together.

The last 2 formulas are beer formulas, which don't work for wine, and the first 2 do not implement FermCalc's published formulas correctly.

The correctness of the initial and final readings are on the user. The failure to implement a simple formula correctly makes me question everything FermCalc publishes.

This doesn't matter to you? Cool. But it does matter to others.

 

[balatonwine]

I'm an IT professional with extensive experience in dealing with the errors produced using real numbers.

The issue is not about errors in real numbers, but in understanding that we are dealing with measurement data, which is not exact and has uncertainty. And thus we are dealing with not exact numbers but with numbers that have statistical properties. Ergo, a measurement of 0.995 has uncertainty of +/- 0.001 value. And that uncertainty will propagate through the calculations and the result is not a fixed value and its uncertainty should be accounted for. One way is to use significance arithmetic. Which is not the same as simple rounding.

For example, if we take two measurements, 8 and 8, each with a precision of 1, and multiply them the "correct" answer is not 64. Even if a calculator says it is. Because we must account for uncertainty. Rather one should represent the uncertainty of the result as either 6x10^1 or 64+/-8.

Ergo, since we have a level of uncertainty 14.4 is really 14.4+/-0.1. And thus one can not directly compare 14.4 and 14.3 and call one wrong, because of the uncertainty both are estimating the same unknown value, and both values overlap, thus one can not call one answer wrong versus another. Thus and why I keep saying:

Their implementation is incorrect.

You have not proven it.

And I again say, I am not saying you are wrong. You may be right. But simply that your method of "proof" here is not actually proof.

Why, may one ask, are then your results different from theirs? To answer that, and to provide real proof, one would need to deconstruct their JS code, and look at your Excel code for example, and compare. For example, if they are using significance arithmetic it should be done in large calculations only once. If their code applies it between different formulas then that may inject rounding issues. If this is done in an avoidable place, then I agree their implementation may need adjustments. But there are also some unavoidable source, such as pre-processing in any hydrometer correction formula and typing in that value (may inject some rounding error) rather than using it directly in one large formula. In the latter case, I would say their implementation is not optimal, but also not a failure.

Of course, I assume you have contacted FermCalc about your concerns. And not simply reported it here. They may provide you with the best answer.

Hope this helps.

 

[balatonwine]

The failure to implement a simple formula correctly makes me question everything FermCalc publishes.

Side note: FermCalc uses Javascript. Which may implement decimal numbers differently than some products like your calculator or Excel. If you work in IT you should already know this (0.1 + 0.1 + 0.1 - 0.3 in your calculator or Excel gives 0, but in JS, it will be 5.551115123125783e-17). And there are many underlying libraries that FermCalc may or may not use that may be an issue. Ergo, saying FermCalc (implied "alone") can not implement a "simple formula correctly" may be accurate, or it may be incorrect. The later may be liable. Just something to think about. Be careful.

 

[balatonwine]

I have to laugh.

I have completely solved this issue to my satisfaction. So simple, yet far too much work on my part to get there.

So, being a bit curious, I decided to take my own advice and took the time to unwind the JS code and step through it (which is not easy when the code is compressed and obfuscated). The Berry method give a value of 14.4 in the source code, but then sends this value into another modifying function, which was recursive and complex, which returned a value of 14.5 for the Berry method. Of course, my first thought it was a temperature/volume correction method. So wondering why if temperature was changing the value, why, as I did not change the default temperature of 68°F.

So, when in doubt read the manual. Which is when I started to laugh. It was right there all along. So much comment here, so much time wasted, so many claims of failure or no failure.....

This method has a temperature basis of 15.56°C (60°F).
​

So, adjust the temp to the correct basis for this method to 60°F and you get the same answer as in Excel: 14.4. Which means, using Excel, or a calculator, only works at that temperature. While this FermCalc formula will correct the ABV depending on actual temperature at time of measurement. Seems better to me and thus maybe far from being a "failure". I would trust it (especially after a few hours playing with the actual code, I have some under the hood experience with it).

So again, first fully reading and understanding the manual saves a lot of grief. How could I forget that?????

For me this issue is solved and is closed.

 

[winemaker81]

@balatonwine, the uncertainty of the correctness of the inputs is of no importance in this discussion. Every equation relies on the correctness of the inputs, and there's no way to take user error into account.

Using your analysis I realized that FermCalc is messing with the inputs. According to what you found, the basis for the formula is 60 F, yet FermCalc's default temperature is 68 F:



Note The Corrected SG line shows the inputs at their original value.

Now change all temperatures to 60 F:



FermCalc altered the Corrected SG values. They should have done the reverse, adjusted for 68 F, not adjusted for 60 F.

Personally, this is not wasted time. It was a problem to solve and we identified the source of the error. Brain teasers are good!

 

[balatonwine]

....this is not wasted time. It was a problem to solve and we identified the source of the error. Brain teasers are good!

I do like brain teasers.

But..... at my hourly rate for software error analysis, and this being unpaid software analysis, it was kind of a loss. For that lost revenue, I could have gotten all my 7 varieties of wine tested using a gas chromatograph; much more accurate than any online calculator.... haha.

 

[Bmd2k1]

and my original question was -- How do you calculate your ABV? Doesn't require more than 1 significant digit for the vast majority of Us

 

[winemaker81]

and my original question was -- How do you calculate your ABV?

I answered that in the first post!

ABV = (InitialGravity - FinalGravity) / 7.36 * 10