I have a column of positive and negative numbers, which when summed should balance to zero (it's an accounting sheet).
However, if I use a SUMIF formula, instead of 0, i get:
1.81899E-12 or -9.09495E-13 or similar. (I don't know what this sort of result is called, but I think they represent very large or very small numbers)
I have created a sample document which shows the issue.
It returns a zero if the cell is formatted as a number, but the above result if formatted as general.
I often also find that even the simple SUM function also returns a similar result, as does the SUM in the status bar at the bottom of excel, so it is not just the SUMIF function I am struggling with. However, I have been unable to recreate the issue with the SUM function in my example spreadsheet.
I'm using Excel as part of Home and Business 2013.
Thanks for your help.
As #Dominique pointed out, xxxE-12 is a very, very small number. It is very, very close to zero.
xxxE-12 is Excel's (and most programming languages') way of writing xxx * 10^-12.
As you guessed, this is due to rounding. It however also displays the issues of how computers handles floating-point (decimal) numbers; what you think is 1 / 3 = 0.333 might be represented internally as something like 0.333333681. See https://en.wikipedia.org/wiki/Floating-point_arithmetic, or notably https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems.
Secondly, why this appears if the cell is formatted as "General", but not "Number"? With "Number", you expect an integer part and at most, say, 3 decimals. x.xxE-12 has the largest non-zero component at the 12th (!) decimal. So when displayed, it gets rounded to a nice zero. "General" however attempts to display the number as close to the actual value, which in this case is the xxxE-12.
Also note that this might give you issues if you try to compare your calculated value with zero. Say, =IF(SUMIF(...) = 0, ...; it might not evaluate to TRUE even when you think it does (due to the very small value). The solution is instead to compare the difference of calculated value to zero: =IF(ABS(SUMIF(...) - 0) < 1E-9, ....
Related
A colleague of mine sent me their Excel sheet and asked me to take a look at it. The issue is that with a very specific number (56136.598), Excel is automatically extrapolating that number out to 10 decimal places completely regardless of the formatting options.
The cell displays the number to the correct 3 decimal places, but if you look at the number in the formula bar it displays all 10 decimal places. It even changes the number to 10 decimal places if I write the formula =round(56136.598,3) to =round(56136.5979999999,3).
Unfortunately, given the industry I am in, I need some explanation as to why this very specific number induces this change. It's not enough to just use a round or trunc function to lop it off at 3 decimal places, the fact that this number and this cell have a different set up then the rest of the parallel cell calculations is drawing some criticism. Has anyone ran into this before? I have tried it in Excel 2010 and 2019 and in new worksheets, same issue. It seems that excel refuses to accept the number at 3 decimal places and forcing an expansion to 10 decimal places on its own.
This is a normal behavior. See the image below where I just entered 56136,598 into the cell.
This happens due to the fact that Excel is a numeric calculation program and not an algebraic one. So it is a problem of precision. Also see Numeric precision in Microsoft Excel.
Excels results are not absolute but very close to correct. The difference between these to numbers is almost 0 (the difference is 0,0000000001).
And this is actually how most common calculators will act too (you just don't see that). It is just the nature of how calculators (and computers) work.
So there is nothing to worry about.
More about this: Understanding Floating Point Precision, aka “Why does Excel Give Me Seemingly Wrong Answers?”
Excel is rounding numbers inconsistently that is causing me issues. When using ROUND(), sometimes it rounds a specific number up, while at other times it rounds the same value down.
I've tried setting Excel to show exact values in settings, but it doesn't change anything.
This is an example of what is happening.
This is the simple formula ROUND((A1-B1)/2,4)
For one record I have the values (.3159 - .3152) which evaluate to .0007 then divide by 2 to get .00035.
For the next record I have the values (.3554 - .3547) which also evaluates to .0007 and divided by 2 results in .00035
So, even though both values are .00035 when I round off to 4 decimal places I am getting .0003 for one and .0004 for another. Same number, rounding to the same number of places, two different results. How can I fix this?
This is an issue with floating point numbers that is inherent and cannot be solved, only avoided.
Try these tests in Excel:
=(0,3159-0,3152)=(0,3554-0,3547) gives you FALSE.
=(0,3159-0,3152)-(0,3554-0,3547) gives you something like 5.55112E-17.
If you cannot accept the differences, you should round already in the middle of the calculation, not only at the end:
=ROUND(0.3159-0.3152,4)=ROUND(0.3554-0.3547,4) is TRUE
=ROUND(0.3159-0.3152,4)-ROUND(0.3554-0.3547,4) is 0
further reading: Is floating point arithmetic stable? and Binary floating point and .NET, by highly regarded Jon Skeet.
I am very new to Excel and I have a problem with a simple multiplication (I know, it is depressing but I'm stuck).
I have to multiply the numeric content of 2 cells (these value are calculated using 2 different formulas).
The problem is that it seems that these 2 cells contain numeric values having different format and I obtain a strange result.
Infact I have:
1) The K3 cell containing this value: 0,0783272400
2) The K6 cell containing this value: 728.454911165
In another cell I simply do:
=K3*K6
but now I am obtaining this nonsense value: 57.057.862.655,9996000000
I think that the problem could be related to the fact that the first one use the , do divide integer section and decimal section, and in the other one I am using . to divider the integer section and decimal section.
How can I correctly handle this situation?
Format both values as Currency in Excel and forget about the issue.
You are getting it, because the floating point values are not represented differently in many programming languages. In Excel probably the best way to make sure you do not give strange values is to format as Currency.
Or in VBA to use the CDec and to convert to decimal.
Is floating point math broken?
Excel is treating 0,0783272400 as something less than one tenth and 728.454911165 as getting on for one thousand billion. The result is formatted with . for thousands separator and , for decimal separator - and is not nonsensical (though the choice of formatting is).
I am calculating the geometric mean of a row in MS Excel by using the GEOMEAN(...) command.
What is the geometric mean: The row could be A1:A10. A geometric mean with
GEOMEAN(A1:A10)
is the product of all 10 cell values (multiplied together) after which the 10th root is taken (mathematically: nth_root(A_1 x A_2 x ... x A_n) ).
The issue: The command GEOMEAN(A1:A10) works fine as long as no cells contain negative values (actually just as long as the product ends up positive). If one cell has a negative value, then taking the root is mathematically an invalid action and Excel gives an error.
The solution: I can work-around this by adding a large enough number such as +1000000 to each value before doing GEOMEAN(A1:A10) and afterwards subtracting -1000000 from the result. This is a mathematical approximation to the pure geometrical mean.
The question: But how do I add +1000000 to each value in Excel? A solution would be to create a whole new extra row where the number is added, and then doing GEOMEAN on this row and subtracting the number from the result. But I would really like to avoid creating a new row, since I have many long data sets to perform this command on.
Is there a way to add the number inside the command itself? To add it onto each value before it is multiplied? Something along the lines of:
GEOMEAN(A1:A10+1000000)-1000000
Solution to avoid the work-around
Based on the answer from and discussion with #ImaginaryHuman072889
It turns out that a working command that avoids any work-around is:
IFERROR(GEOMEAN(A1:A10);-GEOMEAN(ABS(A1:A10)))
If an error are cought by the IFERROR, then we know that a negative result would have appeared, so this is constructed manually in that case.
BUT: This does not take into account the case mentioned by #ImaginaryHuman072889, though, because Excel seems to forbid any negative numbers involved and not just if the inner product is negative. For example, both GEOMEAN(-2,-2) as well as GEOMEAN(-2,-2,-2) give errors in Excel, even though they both should be mathematically valid, giving the results 2 and -2, respectively. To overcome this Excel-issue, we can simply write out the exact same command line manually:
IFERROR(PRODUCT(A1:A10)^(1/COUNTA(A1:A10));-(PRODUCT(ABS(A1:A10))^(1/COUNTA(A1:A10)))))
I add this solution to aid any by-comers who have the same issue. This mathematically works, but the fact that -2 and -2 have the geometrical mean 2 does seem a bit odd and not at all like any useful value of a "mean". It is still mathematically legal as far as I can find (WolframAlpha has no issue with it and the Wikipedia article never mentions a sign).
Your "workaround" of doing this:
GEOMEAN(A1:A10+1000000)-1000000
Is completely wrong. This is absolutely not equal to GEOMEAN(A1:A10).
Simple counter-example:
GEOMEAN({2,8}) returns the value of 4, which is the geometric mean of 2 and 8.
GEOMEAN({2,8}+1)-1 is equal to GEOMEAN({3,9})-1 which is approximately 4.196.
What is a valid workaround is if you multiply each value inside GEOMEAN by a certain value, then divide the result by that value.
Simple example:
GEOMEAN({2,8}*3)/3 is equal to GEOMEAN({6,24})/3 which is 4.
However, this method of multiplying by a constant does not help your situation, since this won't get rid of negative values.
Mathematically speaking, the geometric mean of a positive number and a negative number is an imaginary number, which is presumably why Excel cannot handle it.
Example:
2*-8 = -16
sqrt(-16) = 4i
Therefore, 4i is the geometric mean of 2 and -8. Notice how it has the same magnitude as GEOMEAN({2,8}), just that it is an imaginary number.
All that said... here is what I recommend you doing:
I suggest you return two results, one result is the magnitude of the geometric mean and the other is the phase of the geometric mean.
Formula for magnitude:
= GEOMEAN(ABS(A1:A10))
(Note, this is an array formula, so you'd have to press Ctrl+Shift+Enter instead of just Enter after typing this formula.) The use of ABS converts all negative numbers to positive before the GEOMEAN calculation, guaranteeing a positive geometric mean.
Formula for phase, I would just do something like this:
= IF(PRODUCT(A1:A10)>=0,"Real","Imaginary")
Which obviously returns Real if the geometric mean is a real number and returns Imaginary if the geometric mean is an imaginary number.
EDIT
Technically speaking, some of what I said wasn't completely precise, although the magnitude formula above still stands.
Some things I want to clarify:
If PRODUCT(data) is positive (or zero), then the geometric mean of data is positive (or zero).
If PRODUCT(data) is negative and if the number of entries in data is odd, then the geometric mean of data is negative (but still real).
If PRODUCT(data) is negative and if the number of entries in data is even, then the geometric mean of data is imaginary.
That said... if you want these formulas to be a bit more technically accurate, I would modify to this:
Adjusted formula for magnitude:
= GEOMEAN(ABS(A1:A10))*IF(AND(PRODUCT(A1:A10)<0,MOD(COUNT(A1:A10),2)=1),-1,1)
Adjusted formula for phase:
= IF(AND(PRODUCT(A1:A10)<0,MOD(COUNT(A1:A10),2)=0),"Imaginary","Real")
If the geometric mean is real, it returns the precise geometric mean (whether it is positive or negative), and if the geometric mean is imaginary, it returns a positive real value with the correct magnitude.
So, I just found the answer - although I have no idea why this works.
Doing GEOMEAN(A1:A10+1000000)-1000000 is actually possible. But by pressing enter and error #VALUE is displayed. You must click control+shift+enter to have the actual result displayed.
According to this: https://www.mrexcel.com/forum/excel-questions/264366-calculating-geometric-mean-some-negative-values.html
If anyone has an explanation for this, I am very interested.
Does anyone know why Excel gives different answers to the same question when using SUM function or not?
If you type in:
=0.1+0.1+0.1-0.3
You get a different (correct) response of 0 compared to:
=SUM(0.1+0.1+0.1-0.3)
Which gives an incorrect answer of 5.55112E-17.
I understand that Excel uses the IEEE 754 and that explains why the second is off, but what I would like to know is how the two differ, and what does the first do to get it correct?
This is taken from Microsoft's page explaining floating-point arithmetic:
Example when a value reaches zero
In Excel 95 or earlier, enter the following into a new workbook:
A1: =1.333+1.225-1.333-1.225
Right-click cell A1, and then click Format Cells. On the Number tab,
click Scientific under Category. Set the Decimal places to 15. Instead
of displaying 0, Excel 95 displays -2.22044604925031E-16.
Excel 97, however, introduced an optimization that attempts to correct
for this problem. Should an addition or subtraction operation result
in a value at or very close to zero, Excel 97 and later will
compensate for any error introduced as a result of converting an
operand to and from binary. The example above when performed in Excel
97 and later correctly displays 0 or 0.000000000000000E+00 in
scientific notation.
It appears as though the optimization mentioned in the last paragraph is not applied if brackets are included in the calculation - perhaps it disrupts the calculation sequence. For example:
=0.1+0.1+0.1-0.3 = 0
However:
=(0.1+0.1+0.1-0.3) = 5.551115123125780E-17
Yet, the miscalculation is not only applicable to those numbers in brackets but also the numbers outside, provided there are brackets in the formula. So:
=0.1+0.1+0.1-0.3+(0.1+0.1+0.1-0.3) = 1.110223024625160E-16
This calculation gives twice the error in it's calculation despite the first part not being parenthesised.