I have a excel sheet with a few formulas like this:
A1,A2,A3= 0.13,1.25,2.21
A4: =(A1*A2) =0.16 ( 2 decimal points)
A5: =(A2*A3) =2.76 ( 2 decimal points)
A6: =SUM(A4;A5) =2.93 ( 2 decimal points )
And i want to show 0.16+2.76=2.92
well, there's my problem in bold. i want to add the values from the cells, not the formuls result. How can i do that ? Thank you
Presumably you're working with money which is why you need this.
One way to resolve this is to use =ROUND(A1*A2, 2) etc. and base your subsequent calculations from that.
Do be aware though that you will still occasionally get spurious results due to Excel using a 64 bit IEEE754 floating point double to represent numbers. (Although it does have some extremely clever circumvention techniques - see how it evaluates 1/3 + 1/3 + 1/3 - it will not resolve every possible oddity). If you're building an accounting-style sheet you are best off working in pence, and dividing the final result.
Round the values before you sum, ie:
=ROUND(A1*A2,2)
=ROUND(A2*A3,2)
You could wrap your formulas with the ROUND function:
=ROUND(A1*A2,2)
This will give you 0.16 as opposed to 0.163. Do this for each of your calculations and you'll only be calculating everything to two decimal places. Although I'm not sure why you'd want to do that.
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?”
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).
Using Excel 2013, typing this into two cells yields different results.
=ROUND((10.45-10.00)/1,1) = 0.4
but
=ROUND(0.45/1,1) = 0.5
And I have no idea why this is the case. Anyone have an explanation?
Because Excel uses floating-point math, so results are not guaranteed to be exact. On my Excel 2013 installation, if I enter =10.45-10.00 in a cell, then change that cell to Number with 30 decimal places of precision, the actual answer is 0.449999999999999000000000000000. Since 0.44999... and 0.45 are on opposite sides of the rounding boundary, they round to one decimal place differently.
Edit See also this answer and the question and other answers, which go into much more detail about why Excel's math is inexact.
It looks like the top calculation is creating an infinitesimally small difference. To see this, pull the formula out of the ROUND function. Using the "Increase Decimal" button, expand both values to 15+ decimal places. You'll see that the top value is actually 0.449999999999999.
I have no idea why it actually does this.
So I'm creating a spreadsheet that determines the cost of materials and the number of each material needed in order to complete a desire project using input from myself. Right now the desired project is a wall that is 250x9 that requires replace all the 4x8 sheets of wood with OSB and install Vinyl Siding. The issue I'm running into is I cannot get it to always round up. By that I mean even if the value is 1.1 it should round up. In this specific case I am buying nails for my nail gun in a box of 2,000 and each sheet of OSB will have 32 nails in it. If 250x9 area requires 70.3125 sheets of OSB it means I still have to buy 71 sheets of OSB. If that OSB is 71 sheets then it require that I have 2272 Nails then the result is I need 1.125 Boxes of nails. However I can't seem to get it to show this as 2 boxes because again I still need to purchase more than one box to complete the project. So with that being said if I take the number of OSB needed 70.3125 and I place it in a formula with a roundup function it still rounds down (gives me a headache that there is a roundup and a rounddown function and it will still round down on me. Perhaps it is the way I am using it in the formula that is incorrect, I'm not sure. So let me translate the formula's used and you can let me know if I'm doing something wrong or if there is a function or set of functions that I can use to solve this issue.
=SUM(((B30*C30)+(B35*C35)+(E30*F30)+(H30*I30))/(E9*G9))
This says that if I added Wall1 L*W with Wall2 L*W with Wall3 L*W with Wall4 L*W and divide it by OSB H*W I get the number of sheets needed. Which in this case is 2250/32 basically. But its programmed in a manner that I can input the information for individual walls to different area's and get it to spit out the total SqFt for each wall and give an individual breakdown per wall of material needed with cost associated per sq ft of material bleh bleh bleh. The point is I take the result that is the 70.3125 and I move it to a different workbook and I say "Sheets OSB Needed" and in that box I have
=ROUNDUP(Sheet1!A9,1)
Whereas I'm asking it to roundup A9 which is the result of the above formula by intervals of 1. But the output is still 70 instead of 71. and much the same case with the nails needed. Which can be calculated in a few different manners but regardless the amount of nails needed divided by 2000 would output the decimal answer which yields a value of less than 1.5 and it too provides me with a value of 1 instead of 2 with much the same formula. I could achieve my desired result I suppose with Trunc and Mod functions collaborating using multiple cells to output the different portions of the data. But is there a way to do this that doesn't involve so many cells being used up?
C7
=Trunc(A9)
Removes Decimal from 70.3125
C8
=MOD(A9)
Outputs decimals from 70.3125
C9
=IF(C8<1,"1",C8)
If Decimals are < a whole number make it a whole number
C3
=SUM(C7+C9)
Add the whole number to the Trunc Number to get value desired.
Which I'm already seeing an issue with this if there is no decimals in the sheets needed then wouldn't it always add one because the decimal place would be 0? How can I handle this issue? Isn't there an easier way to do this or a way to code it so that its all nested into one calculation or at least mostly all into one calculation without making a circular reference of some sort?
You need to change the second parameter to a 0 ROUNDUP(70.3125, 1) is 70.3 the 3 must be getting dropped elsewhere or lost in formatting.
ROUNDUP(70.3125, 0) will give 71.
The second parameter of round up is the decimal place. So to round to integers it should be 0 not 1
How can I generate those numbers in Excel.
I have to generate 8 random numbers whose sum is always 320. I need around 100 sets or so.
http://en.wikipedia.org/wiki/User:Skinnerd/Simplex_Point_Picking. Two methods are explained here.
Or any other way so I can do it in Excel.
You could use the RAND() function to generate N numbers (8 in your case) in column A.
Then, in column B you could use the following formula B1=A1/SUM(A:A)*320, B2=A2/SUM(A:A)*320 and so on (where 320 is the sum that you are interested into).
So you can just enter =RAND() in A1, then drag it down to A8. Then enter =A1/SUM(A:A)*320 in B1 and drag it to B8. B1:B8 now contains 8 random numbers that sum up to 320.
Sample output:
I'm a bit late to the game here - but fyi if only integers required then:
=LET(x_,RANDARRAY(8,1,1,1000000,1),y_,ROUND(x_*320/SUM(x_),0),y_)
is somewhat similar to the favourite soln above, albeit parsimonious (formula in single cell required to produce desired array , no helper column). Also addresses insignificant decimal points, albeit you may need to allocate back the deficit / surplus due to the occasional rounding error which may yield a sum total of 321 or 319. Could do this in a random fashion again using something like index(y_,randbetween(1,8))+320-sum(y_) in formula above - or resort to the infamous helper fn..
Someone commented the favourite soln above (and thus mine, since it stems from a similar concept/approach) is not uniform - I'm not sure this was required; a uniform spread would impede the random nature (and is arguably far simpler as you simply divide a sizeable range into distinct octiles, and follow the same approach already laid out here - not sure where/why the notion that a random spread should be arbitrarily/mechanically 'forced' to adopting some type of non-random spread.. anyways... I obviously haven't read the problem properly (ehem).
I'm a bit late to the game here - but fyi if only integers required then:
=LET(x_,RANDARRAY(8,1,1,1000000,1),y_,ROUND(x_*320/SUM(x_),0),y_)
is somewhat similar to the favourite soln above, albeit parsimonious (formula in single cell required to produce desired array , no helper column). Also addresses insignificant decimal points, albeit you may need to allocate back the deficit / surplus due to the occasional rounding error which may yield a sum total of 321 or 319. Could do this in a random fashion again using something like index(y_,randbetween(1,8))+320-sum(y_) in formula above - or resort to the infamous helper fn..