We have some weird calculation scenario in Microsoft excel, this simple addition operation resulting 1 at 13 decimal digit whereby it should be zero
But when i extract the value in formula the result is correct (both formula value is the same but the result is different)
From human understanding addition calculation will reduce the decimal digit rather than add it.
Is this by design or bugs ?
I strongly guess that this is a gap from the limited precision of floating point numbers. Accuracy of digital numbers is limited. Numbers in excel are saved in binary format(but displayed in decimal format). This means that the "0" is not as protected as in the decimal system. Usually Excel tries to cover this up for examples like yours.
Also, if your numbers derive from complex calculations (e.g. square-roots), the accuracy can be limited as most functions use approximation with limited iterations to give a result.
You can find more information about floating point arithmetic here. The blog is about pythin but the way it works is similar.
https://docs.python.org/3/tutorial/floatingpoint.html
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?”
A friend of mine discovered a really weird thing in MS Excel. Excel rounds down some specific numbers the wrong way, actually it rounds down a number that shouldn't need rounding.
As far as I have tested, it happens in most versions of MS Excel 2007+
Eg. the number 10358.165790 will be rounded down to 10358.1657899999.
Apparently it only happens in this interval: 8192.165790 - 65535.165790.
It is really weird - it doesn't happen with eg. .165890 or .165690, only with .165790.
Do any of you know why this happens and why it only accounts to certain numbers?
Excel uses an IEEE754 64 bit double precision floating point type to represent numeric data; with some clever formatting and roundup tricks to get sums like 1/3 + 1/3 + 1/3 correct.
What you are observing is a natural consequence of that numeric scheme only being accurate to 15 significant figures. Unless the number happens to be a dyadic rational, in which case it can be stored exactly, the closest representable number is chosen to the one you actually want. This may be below or above a rounding cutoff.
It will occur in other ranges other than the one you cite too.
I am looking for any documentation on the decimal precision in Postgres and Excel.
I have a database which was imported through excel. I am finding that the SUM() result in excel is slightly different than the SUM() method in Postgres (usually at the 3rd or 4th decimal place depending on what i include or exclude from the data. I am curious to see if this is because of a floating point precision issue, or if there may be some small differences resulting from the import.
You find documentation for Postgres in the manual.
PostgreSQL's decimal is not a floating point number, but an arbitrary precision number. Additions like sum() are exact in Postgres.
The types decimal and numeric are equivalent. Both types are part of the SQL standard.
In contrast, MS Excel operates with limited accuracy. Quoting Wikipedia at the site #Tim provided:
As with other spreadsheets, Microsoft Excel works only to limited
accuracy because it retains only a certain number of figures to
describe numbers (it has limited precision)
Discrepancies are to be expected. You might try PostgreSQL's double precision type, which seems a better match. I doubt, you'll get a 100% match, though.
I have put two date time values in cells A1 and B1. The date time is precisely 41703.0416666667. One is ouput from an SQL database the other manually written.
The result of =if(A1=B1,1,0) is 1.
The result of =MATCH(B1,A1,0) is #N/A.
Does anyone have any theories as to why this may be happening?
Probably an issue with converting decimal to binary. See related answer:
Simple HLOOKUP Failing with Excel 2010
This appears to be a limitation of storing floating point numbers in binary - as described here: http://support.microsoft.com/kb/214118
Many combinations of arithmetic operations on floating-point numbers
in Microsoft Excel and Microsoft Works may produce results that appear
to be incorrect by very small amounts. For example, the equation
=1*(.5-.4-.1) may be evaluated to the quantity (-2.78E-17), or -0.0000000000000000278 instead of 0.
This problem is not unique to excel either but rather a result of:
IEEE 754 specifies that numbers be stored in binary format to reduce
storage requirements and allow the built-in binary arithmetic
instructions that are available on all microprocessors to process the
data in a relatively rapid fashion. However, some numbers that are
simple, nonrepeating decimal numbers are converted into repeating
binary numbers that cannot be stored with perfect accuracy.
The issue is with the floating-point calculation (see http://support.microsoft.com/kb/78113), one possible workaround is to work with the round() function. In your case, rounding to 10 or 12 decimals would probably be enough to address the issue.
I was doing a "percentage change between two numbers" calculation, and I initially wrote it as (using Excel 2013):
=(NEW NUMBER - OLD NUMBER)/OLD NUMBER
I changed it to:
=NEW NUMBER/OLD NUMBER -1
.. to test to see if it was any faster with a large spreadsheet. Like I often do, I checked to see if the generated numbers were all equivalent (using a coerced CellColX = CellColY formula), and about 80% of them were, but others weren't -- by a tiny amount. I watched the action in the Evaluate Formula tool and expanded out the decimal places in the cells to where it was returning all 0's.
For instance, OLD NUMBER = 10.44 and NEW NUMBER = 10.86 resolves to 0.0402298850574713 using the first method, and 0.0402298850574712 using the second method.
However, OLD NUMBER = 13.17 and NEW NUMBER = 10.44 resolves to -0.207289293849658 using either method.
(The OLD and NEW numbers are genuine 2-place decimals.)
Mainly for OCD sake, is there a known reason for this? And is there any significance for very sensitive calculations?
is there a known reason for this?
As explained in Comments, Yes:
As with other spreadsheets, Microsoft Excel works only to limited accuracy because it retains only a certain number of figures to describe numbers (it has limited precision). Excel nominally works with 8-byte numbers by default, a modified 1985 version of the IEEE 754 specification[1] (Besides numbers, Excel uses a few other data types.[2]) Although Excel can display 30 decimal places, its precision for a specified number is confined to 15 significant figures, and calculations may have an accuracy that is even less due to three issues: round off,[3] truncation, and binary storage.
(From Wikipedia.)
is there any significance for very sensitive calculations?
Also Yes, and I suggest not just for very sensitive calculations, rather often where very large or very small numbers are involved in calculations. However because 'very large and 'very small' for normal scales are at the astronomical or anatomic level they are not very often encountered by Excel users. Though there are plenty of examples on SO, eg here and for Google Sheets.
Where these approximations cause problems on a regular basis is, as you have noted, in comparisons. Without rounding results that should be (mathematically) the same may not be and =EXACT or just = may return FALSE falsely.