I am expecting the result after rounding for 161.24 to be 161.5 and if the value is 161.75 then it must be rounded to 162, if it is 161.68 then it must be rounded to 162
I have used =MROUND(value, "0.5") but I dont get the expected result.
For what you expected, you should use:
=CEILING.MATH(value,0.5)
Related
I have been trying to apply some conditional formatting to numbers which are formatted externally as fractions with a mask ???/???. In trying to test whether the fraction has a numerator of 1, I apply the formula = =MOD(1/G62,0)<>0, which divides 1 by the fraction itself, which ought to divide with no remainder if it has a numerator of 1, and return 0. If it returns something else then it has a numerator other than 1.
The rule is satisfied when it should not be. To test what is going on, I deconstruct the formula.
The fraction 1/28 is divided into 1 to give 28 and this is correctly displayed. I then populate another cell using the formula =MOD(H62,1) to 28 and it gives 0, as it should. I do the same thing for 1/14 and the result is 1. In other words the MOD of 14, 1 is 1! When I look at the decimal representation of the 2 fractions( I imagine the fractions are actually the representations of the decimal numbers, which themselves will be binary or hex numbers internally), I see the following.
1/28 0.0357142857142856
1/14 0.0714285714285716
When the decimal for 1/28 is subtracted from the decimal for 1/14, the result is 0.035714285714286.
As 1/28 can probably never be accurately represented in decimal, it looks like some rounding down has taken place. Most probably when MOD is applied to the decimal representation of 1/28 with 1, that decimal representation of 1/14 does not divide equally into 1, and this discrepancy is disclosed by the subtraction above.
I am using excel 2016. Maybe this is no longer a problem.
What I am trying to do is test to see if the lowest numerator of a fractional number is 1. Perhaps there is another way to do this in Excel. If so, let me know.
Here is my excel table:
The cell with 8.83 = =((C8-B8)*24)-D8
*C8 = 4:50PM
*B8 = 7:30AM
*D8 = 0.50
The cell $371.00 = =(E8*B3)
Why does my total show $371.00 when B3 = $42? It should be $370.86. I don't have it set to round but for some reason it keeps on doing it.
Because, the actual result of formula =((C8-B8)*24)-D8 is 8.833333333. Due to cell formatting you are seeing 8.83. If you want result for only two digit after decimal point then use round function like-
=ROUND(((C8-B8)*24)-D8,2)
Then you will get result 370.86. Or you can directly use in resulting cell.
=ROUND(E8,2)*B3
$371 is “technically” the correct amount, mathematically. You are actually doing rounding when you are hand-calculating your cross-check, and that isn’t matching Excel’s unfounded calculation.
( 4:50pm - 7:30am ) is 9.3333333 repeating, or “9-1/3”. Divided by 24 leaves you 8.8333333 repeating, not 8.83. Excel is doing what it’s supposed to do, and 371.00 is the correct amount. If your use case calls for times to be rounded to .01 hours and no further then you’ll need to apply rounding somewhere in cell E8.
I am trying to write a rounding if statement. If cell <50 round to the nearest 5, if cell is >50 but <1000 round to the nearest 10, if cell is >1000 round to the nearest 100. Can anybody help me out?
My attempt
=IF((T2<50, ROUND(T2*2,-1)/2),IF(AND(T2>50,T2<1000,ROUND(T2,-1)),ROUND(T2,-2)))
I was able to write a similar statement (If cell >0 but <1000 round to nearest 10, otherwise round to nearest 50)
=IF(AND(S3>0,S3<1000),(ROUND((S3),-1)),(ROUND((S3)*2,-2)/2))
Try this:
=IF(A1<50,MROUND(A1,5), IF(AND(A1>=50,A1<1000),MROUND(A1,10),MROUND(A1, 100)))
The MROUND operator (documentation here) rounds to the nearest multiple, which I think is what you're looking for. You also have some issues with your paren grouping, but excel doesn't make it easy to chain if statements. Your AND statement needs to wrap just just the two evaluations and return MROUND(<cell>, 10) when true.
Did you just get a bit mixed up with the IF syntax?
=IF(T2<50, ROUND(T2*2,-1)/2,IF(AND(T2>50,T2<1000),ROUND(T2,-1),ROUND(T2,-2)))
The general form is
IF (logical test, result if true, result if false)
You also had some unnecessary brackets and didn't close the AND brackets.
I frequently use the nullif when value equals to zero, and wondering if it's possible to also display null when it equals to negative number? My current formula is NULLIF({quantity}-{quantityshiprecv} ,0) but this displays negative numbers when {quantityshiprecv} is greater than {quantity}, and I'm hoping to display null.
You just need to modify the first argument to return 0 if {quantity}-{quantityshiprecv} is negative, but still give the correct answer if it's positve. Here's one way:
NULLIF(({quantity}-{quantityshiprecv} + ABS({quantity}-{quantityshiprecv}))/2,0)
This adds the absolute value of the difference to the unchanged difference. If the difference is positive, that gives you double what you want. If it's negative the absolute (ABS()) will negate that negative value leaving you with zero. You can then divide by 2; positive is now correct, negative remains zero. The rest of the NULLIF() remains the same.
While converting the hexadecimal value "FFFFFFFF00" into octal value using Hex2Oct of MS Excel, it should return "Error string" as per the rules mentioned here:
If number is negative, HEX2OCT ignores places and returns a 10-character octal number.
If number is negative, it cannot be less than FFE0000000, and if number is positive, it cannot be greater than 1FFFFFFF.
If number is not a valid hexadecimal number, HEX2OCT returns the #NUM! error value.
If HEX2OCT requires more than places characters, it returns the #NUM! error value.
If places is not an integer, it is truncated.
If places is nonnumeric, HEX2OCT returns the #VALUE! error value.
If places is negative, HEX2OCT returns the #NUM! error value.
But it computes and returns as "7777777400" without considering the rules/remarks mentioned in the link.
For example:
While calculating HEX2OCT,
As per Excel rule, If number is positive, it cannot be greater than 1FFFFFFF(hex)<->3777777777(oct)<->536870911(decimal).
But while calculating the HEX2OCT for FFFFFFFF00(hex) <-> 7777777400(oct) <-> 1099511627520(decimal).
Here the hex value FFFFFFFF00 is greater than 1FFFFFFF, but MS Excel does not return the error string instead it returns the converted octal value.
Can anyone explain why?
FFFFFFFF00 is actually well within the range of hex2oct because it is a negative number.
According to that documentation the largest negative number it can handle is FFE0000000 which when converted to decimal is -536870912. Converting your "big" hex over to decimal yields -256.
The reason the value of FFFFFFFF00 looks so big is because it's a negative number. The first bit is set to 1 (when converted to binary) which signifies that the number is negative. Negatives are computed in binary using two's complement which is found by flipping each bit and then adding 1 to the number.
Undoing the two's complement:
For your big number, the binary representation is:
1111111111111111111111111111111100000000
Subtracting 1:
1111111111111111111111111111111011111111
Flipping all the bits:
0000000000000000000000000000000100000000
Which is 256
So.. basically if the hex looks big, but the first bit is 1 then it's actually a small negative and well within your range of allowable values.
Lastly, when you hex2oct you don't get a negative sign for these because we are still not in decimal notation. The first bit of your octal is still a 1 (when converted to binary) since it's still the same number, just represented in a different counting system.
The clue lies earlier in the documentation page you quote:
The HEX2OCT function syntax has the following arguments:
Number Required. The hexadecimal number you want to convert. Number cannot contain more than 10 characters. The most significant
bit of number is the sign bit. The remaining 39 bits are magnitude
bits. Negative numbers are represented using two's-complement notation.
The hex value FFFFFFFF00 corresponds the binary value
1111 1111 1111 1111 1111 1111 1111 1111 0000 0000
and as the documentation says, "the most significant bit is the sign bit ... two's complement notation". So this value represents a negative number. By the rules of two's complement, it actually represents -256. And this is fine, because it is not "less than FFE0000000", as FFE0000000 is -2097152.
If you actually want to treat FFFFFFFF00 as an unsigned quantity, and get the octal representation of decimal 1099511627520, you'll need to use another method.