I am trying to understand tthe associativity of operations when it comes to floating points.
In the lecture notes i have, the following is stated:
"suppose floating-point values store seven digit of accuracy.
Considee the problem of adding 11 numbers together, where one of the numbers is 10^7 and the other ten are 1.
If the small numbers (the 1s) are each added to the large number, one at a time, there is no effect on that number, because the small numbers occur in the eighth digit of the large number ". So here I understood that the result is 1,000,001.
"however, if the small numbers are first added together and the result is added to the large number, the result is a seven-digit accurancy 1.000001 * 10^7"
But both approaches seemed the same to me: we are adding the 10 numbers to the larger number.
Can someone please clarify this problem ?
Thank you
Let's go over the first method first. When the small numbers are added one by one to the large number, the following will happen ten times:
10,000,000 + 1 = 10,000,001
However since the floating-point values store only seven digits of accuracy this last digit, the eight digit, will be rounded in the seventh digit to zero. This operation will happen 10 times, and so the value will remain 10,000,000.
Next let's go over the second method. The 10 number 1's are added together first and so this will sum up to 10. When this is added to 10^7 the following will happen:
10,000,000 + 10 = 10,000,010
Since the floating-point values store seven digits of accuracy this number will remain!
Related
I have a column of data with numbers stored in text.
The numbers look like this: 735999114002665788
If I select any cell in this column and refer to it with the function =value(), the number shows up as 735999114002665000.
As you can see the last three digits are 0. This happens all the time with numbers this long - but NOT with numbers containing less digits.
Am I trying to convert a number that's too large or what's up? Please help! I've tried every form of text-to-number method with identical results :(
Excel's number precision is 15 digits, which is why you're losing the last three digits when converting your 18 character string
https://support.office.com/en-us/article/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3#ID0EBABAAA=Excel_2016-2013
Excel only allows a maximum of 15 digits of precision for each number in a cell. The reason why this number:
735999114002665788
becomes this:
735999114002665000
is because Excel is choosing to retain the 15 most significant digits in the number. This means that the ones, tens, and thousands digits are being tossed out.
By the way, this question has been asked before on SuperUser, and you can read about it here:
https://superuser.com/questions/437764/why-is-excel-truncating-my-16-digit-numbers
I'm currently writing a C program that among other things generates and prints out an amortization table with numbers rounded to two digits. I get the correct numbers everywhere, that is: monthly_payment = principal_paid + interest_paid except in the last row (last payment) where occasionally my results don't add up, and off by one. For example:
MonthlyPay: 88.83, PrinPaid: 87.96, IntPaid: 0.88
Of course looking at the results printed to 6 digits it's easy to see why this is happening:
MonthlyPay: 88.834637, PrincPaid: 87.955087, IntPaid: 0.879551
What's the best way to handle a situation like this?
What do financial institutions do?
There is no standard.
There are those who say, "Once you round, use the rounded value for all further totals."
There are others who disagree, saying that you should sum the unrounded values to avoid accumulated rounding error. For example, 0.0666 + 0.0666 + 0.0666 + ... 15 times should approximately equal 1.0000, but if rounding each term to 2 decimal places before summing, ends up being 0.07 * 15 = 1.05! So that's the argument for using unrounded values. Your off-by-one is only off-by-one because you have just two terms you're summing.
I think ultimately you have to consider the pros and cons of each method. Who would be interested in the rounding errors? Just the programmers? Accounting? Customers? How does it affect those people? And can you issue a statement that clears the ambiguity, like "Values displayed to 2 decimal places." in which case you don't round anything at all, but simply display the first two decimal places everywhere.
Don't round in your calculations. Round only when displaying to end users.
The displayed values might be off by a cent here or there (maybe, but I doubt it). But if you round in your calculations, you'll end up with either total underreporting interest paid and overreporting principal paid, or vice versa.
If you don't round, your calculations will be correct enough that they won't make 1 cent of a difference unless you do massive loan values.
I am trying to capture items that are > 80% to multiply by 3, IF not, to multiply by the percentage given, then round up1]1. However, I'm receiving a message that I have too few arguments for this function.
=ROUNDUP(IF(H2>.79,G2*3*H2,IF(H2<.8,G2*3*H2,0)))
The RoundUP() requires two arguments. The second sets the place to which to round.
=ROUNDUP(IF(H2>.79,G2*3*H2,IF(H2<.8,G2*3*H2,0)),2)
This will round up to the hundredth place. The 2 is the significant diggits in the decimal. To do it to the Tens it would be -1. To the integer 0.
Your call to roundup requires two pieces:
a number to round
a number of decimal places to round to
You have only provided the first. By adding the bolded bit in the formula below (with whatever level of specificity you choose) it will run properly:
=ROUNDUP(IF(H2>0.79,G2*3*H2,IF(H2<0.8,G2*3*H2,0))**,0**)
I know how to isolate the decimal using the TRUNC() function, as well as taking the original value and subtracting this truncated part.
And I can then multiply to get whole number.
But that only works if all my decimals are the same place. I want something that will get me the amount after the decimal point as a whole number, regardless of how many places.
eg: 12.2 would return 2
12.21 would return 21
With data in A1, consider:
=IF(ISERROR(FIND(".",A1)),A1,--MID(A1,(FIND(".",A1)+1),9999))
Naturally leading zeros in the output are dropped:
I have a database which houses scaled integers, the longest being 10 digits long. I am attempting to convert these to decimal values in Excel, moving the decimal point left by 4 digits, i.e. dividing by 10000.
Given that these integers are currently under the 15-digit significant figure limit, and will remain so, is there a possibility that I can encounter rounding errors?
is there a possibility that I can encounter rounding errors?
Strictly speaking I think yes. For example:
but what may be significant is that the discrepancy as shown (all formatted the same, the smaller black ones created by formula, the red ones by difference of those immediately above) is in the tenth decimal place, so hopefully not a problem.