My son found this math game app and I've been playing it. Essentially you have a 5x5 grid of numbers from 0-9, and then at the end of each column and row is a target sum. Every number in the grid can be turned on or off, and when the correct sum is achieved that row or column is highlighted. You can actually play on harder levels, but for an excel problem I decided to try 5x5 just to see if I could get solver to find the answer.
The way I designed this is as follows:
(a) Cells B2-F6 have the number values from the grid.
(b) Cells H2-L6 I put in all zeroes.
(c) Cells N2-S6 I put in as the product of B2 and H2, B3 and H3, etc.
(d) Cells N8-R8 are the sum of N2-N6, O2-O6, etc.
(e) Cells S2-S6 are the sums of N2-R2, N3-R3, etc.
(f) Cells N9-R9 are the target identified by the game.
(g) Cells N10-R10 are N9-N8, O9-O8, etc.
(h) Cells T2-T6 are the target identified by the game.
(i) Cells U2-U6 are T2-S2, T3-S3, etc.
(j) Cell W2 is =MAX(T2:T6,N9:R9)
(k) Cell T12 is =N10*W2^9+O10*W2^8+P10*W2^7+Q10*W2^6+R10*W2^5+U2*W2^4+U3*W2^3+U4*W2^2+U5*W2^1+U6*W2^0
In solver, I set the object of $T$12 to be value of 0, with constraints on variable cells $H$2:$L$6 as <=1, >=0, integer.
However, I can't seem to get solver to find me a solution. I solved it in the game first so I had a solution. When I put that in, solver will tell me it found a solution after changing nothing, or on the evolutionary one it will tell me it hasn't found anything better...of course not, I've already given you the solution. But if you change just one of the 5x5 grid to be wrong, it still can't find a solution. Is this just too complex for solver? It's weird to me that when it fails it has non-integer values in the cells. I keep wondering why it's trying non-integer values when I told it not to (and I did check to be sure my Ignore Integer Constraints box is unchecked). I understand that there are 2^25 different possibilities it should have to try, but there's an infinite number more (okay, maybe finite if it has a maximum number of decimals in the data type, but for all practical, non-quantum purposes, it's infinite) if it ignores my integer requirements. Maybe it's just not comfortable with a brute-force approach and is trying to head a particular direction and just keeps finding that unsatisfactory. I also recognize that my cell T12 formula may be too much for it to handle. It just won't let me have multiple targets so I was trying to come up with a way for it to guarantee no false positives (e.g., if you just add all the difference cells in N10-S10 and U2-U6, which should all be zero, you can actually get solutions where some of the columns are non-zero but add up to zero because of positives and negatives...and those are result cells, so I can't similarly constrain them, I think).
Anyhow, here's the number set:
2 9 3 2 3
9 9 8 4 1
2 6 5 2 6
3 1 6 8 7
6 8 3 6 9
Row totals = 13, 4, 7, 19, 32 from top to bottom
Column totals = 13, 18, 8, 20, 16
I'd give you the answer...but where's the fun in that?
Related
In trying to systematically enumerate the possibilities when rolling four identical but loaded four-sided dice, I came across some unusual excel behavior. Hoping someone can shed some light on what's going on under the hood.
The following table illustrates the possible rolls of a die:
1000 A
0100 B
0010 C
0001 D
each row is a possibility with a distinct probability. In excel, this information can be made to occupy a 4x4 cell area--that is, the letter labels above are merely for convenience.
In trying to display all possible combinations of four rolls of such a die-- where the fist combination might be A + A + A + A or 4000, the second might be B + A + A + A or 3100, and so on for each of the 4^4=256 possibilities--I decided that I wanted to systematically offset A by 0,1,2, or 3 rows for each of four rolls then sum the results. In other words, each possible group of 4 roles can be thought of as 4 copies of row A, each of which offset by some number of rows between 0 and 3, for example {0;0;0;0} or {1;0;0;0} in the first and second case enumerated directly above.
Oddly, though, I get the following. (all formulas are array formulas keyed in with shift+ctrl+enter).
=TRANSPOSE( SUM( OFFSET( A, 4x1ArrayOfRowOffsets, 0)))
displays the correct sum when entered into a 1x4 range. Likewise if =TRANSPOSE(...) is replaced by =INDEX(...,1,1). I take it because both functions natively support array arguments. However,
=SUM( OFFSET( A, 4x1ArrayOfRowOffsets, 0))
does not work--it seems that here the summation is conducted along the 4 rows returned by offset, each of which has value 1--it incorrectly displays only the value 1, even when evaluated in a multicell range as an array formula. Oddly,
=SUM( TRANSPOSE( OFFSET( A, 4x1ArrayOfRowOffsets, 0)))
does not work either--the transpose makes it so the summation is properly conducted along the columns returned by offset, but seems to throw out all but the first column.
Please note that, although the problem statement does not involve VBA, the lack of transparent array formula auditing in Excel proper (intermediate steps return #VALUE errors even when the final answer computes) likely means that, in order to investigate this problem, someone will have to write a bit of VBA that calls worksheet functions and manually outputs the intermediate calculations. This is why I posed a version of this question, here.
Interweaving INDEX calls anywhere but the outside/first function call does not fix the problem.
To try and see what is going on, I investigated further.
=INDEX( OFFSET( A, {w;x;y;z}, 0), 1, {1,2,3,4})
correctly displays the four rolls when entered into a 4x4 range. As before w, x, y, and z are integers between 0 and 3 indicating row offsets from "A" in the table, above. Furthermore,
=COLUMNS( OFFSET( A, {w;x;y;z}, 0))
returns the following when entered into a 5x5 range:
4 4 4 4 4
4 4 4 4 4
4 4 4 4 4
4 4 4 4 4
n/a n/a n/a n/a
All that is to say, calling SUM(OFFSET(---)) with array arguments seems to produce varied output depending on what is doing the calling--specifically, whether or not the caller is a function which natively accepts proper array arguments. Why is this? What is actually going on, here?
Following from the example here I'm trying to add additional conditions to a sum formula. I've represented an example below:
The output that I'm looking for for example for Jan 2017 is
2017
1
UP A 1
UP B 6
UP C 6
DOWN A 1
DOWN B 8
DOWN C 7
I tried with the following formula:
=MMULT(--($B$17:$C$17="X"),MATCH(1,($A23=$C$2:$C$14)*(C$21=$A$2:$A$14)*(C$22=$B$2:$B$14)*($E$2:$E$14=$D$2:$D$14),0))
but I get a N/A value.
Does anyone know it if is possible to do it?
In your first example the number of rows in array1 and number of columns in array2 were equal, five. Here you have two columns and 13 rows. That they are unequal here is part (all) of the reason why you are having an issue.
Also your match function is returning a Boolean not an array
I have a way to do this using matrix condition and multiple criteria but had to change problem up a bit, see photo for example:
{=MMULT(--(D18:P18="x"),E$2:E$14*(--(A$2:A$14=$C$21)*--(B$2:B$14=$C$22)*--(C$2:C$14=A24)))"
https://i.stack.imgur.com/FEvgR.png
You can create a formula to fill the second matrix with X's see below
=IF(OR(INDIRECT("D"&VALUE(D20))=$A$18,INDIRECT("D"&VALUE(D20))=$B$18),"X","")
https://i.stack.imgur.com/4rS4L.png
That being said I don't think this is particularly efficient as you are treating the one of the matrixes as a all 1's so you basically just adding an extra criteria / Boolean with added complexity....that being said u asked for this specifically and I believe that I have delivered that LOL
Just add two SUMIFS together.
=SUMIFS($E$2:$E$14, $A$2:$A$14, C$21, $B$2:$B$14, C$22, $C$2:$C$14, $A23, $D$2:$D$14, IF(INDEX($B$17:$C$19, MATCH($B23, $A$17:$A$19, 0), 1)="x", $B$16))+
SUMIFS($E$2:$E$14, $A$2:$A$14, C$21, $B$2:$B$14, C$22, $C$2:$C$14, $A23, $D$2:$D$14, IF(INDEX($B$17:$C$19, MATCH($B23, $A$17:$A$19, 0), 2)="x", $C$16))
I am working on an Excel sheet where I need to determine the parity of a vertical array of numbers of size N. The array contains each number from 1 to N exactly one time each.
In this context, parity is defined as how many swaps is necessary to convert the scrambled array to a sorted array from smallest to largest.
For example, the array {3;1;2;4} has even parity because it would require two swaps (at minimum) to convert to {1;2;3;4}, but would always require an even number of swaps. See below.
3 --> 1 1
1 --> 3 --> 2
2 2 --> 3
4 4 4
Another example: {2;1;4;5;3} has odd parity because it would require three swaps (at minimum) to convert to {1;2;3;4;5}, but would always require an odd number of swaps. See below.
2 --> 1 1 1
1 --> 2 2 2
4 4 --> 3 3
5 5 5 --> 4
3 3 --> 4 --> 5
I am looking for a solution that would return TRUE for arrays with even parity and FALSE for arrays with odd parity. (And I don't care what the result is for arrays that do not contain all numbers from 1 to N because I have other checks in the spreadsheet to handle those cases.)
I have figured out a solution that uses several helper columns, but it seems like a sluggish calculation.
I do this by checking if each individual number in the array is in the correct index and, if it isn't perform a swap. I then sum up the amount of swaps that occurred and use MOD(<swaps>,2)=0 to determine if it is even parity.
See below for an example calculation with the array {8;5;3;2;4;1;7;6}.
I've color coded the cells to easily tell what is happening:
White = reference array {1;2;3;4;5;6;7;8}
Blue = input array
Grey = "helper" arrays where each successive column performs a swap if necessary
Red = Indicates if a swap occurred from previous column
Green = 1 if swap occurred in that column, and 0 if a swap didn't occur
Yellow = Sum of all green cells, effectively telling how many swaps occurred.
In this example, since the yellow cell is 4, which is an even number, the input array has even parity.
The question is: Can this calculation be done more efficiently in Excel without VBA? I'm not necessarily against helper columns, but again it just seems that my solution is sluggish and I'm wondering if there is a better way.
I think I have a way of doing this without the helper columns!
First, I'll show you a way with N helper columns and then I'll show how to use array formulas instead. Consider the matrix show below:
The green ranges are the indices and the blue range is your permutation. The yellow matrix is your permutation matrix defined as seen in the formula box.
The parity of your permutation is the same as the value of the determinant of this matrix!
Luckily, Excel has a built-in determinant function MDETERM(). An even permutation has parity 1 and an odd permutation has parity -1, so you can get the determinant simply with the formula
=MDETERM(C2:J9)
Now this is pretty cool, but the real kicker is that we don't even need to make that matrix. We can construct it in an array formula like this instead:
{=MDETERM(IF(B2:B9=TRANSPOSE(A2:A9),1,0))}
Here we only use columns A and B! Columns C:J are unused in this version.
(Note that this is an array formula so you will need to use Ctrl+Shift+Enter to validate it. This will wrap the braces around the formula. Don't do that manually.)
How can I return the ranking of each value in a row, even in the case of duplicates? Please see my example below.
While many questions have been answered regarding the handling of duplicate values in a ranking, I have come short in achieving a method that works for all of my cases.
EDIT: The previous picture above was a bad example that did not address my problem. Here is a new picture of the behavior.
In certain cases it skips to 7 when the rank should only be 1:6. In other cases it seems to work, and then not work in similar cases. Data is:
2.61879723030607 2.3428 2.61879723030607 2.4571 2.7324 2.1790
2.97203355745108 2.5355 2.97203355745108 2.6721 3.0561 2.4136
2.4895 2.2781 2.6218 2.4369 2.6898 2.1361
2.32650000000000 2.2124 2.3453 2.32650000000000 2.3938 2.0283
2.34132608128450 2.1331 2.34132608128450 2.2800 2.5758 2.0446
2.58668483692925 2.1476 2.58668483692925 2.3019 2.5124 2.0135
2.2555 2.0884 2.3368 2.0980 2.3928 1.9787
2.32878217762168 2.1080 2.32878217762168 2.1250 2.5360 1.9807
2.50891263421977 2.2480 2.50891263421977 2.4239 2.9070 2.2638
2.97755287506272 2.4457 2.97755287506272 2.6830 3.0566 2.3987
3.0850 2.5380 5.3880 2.8304 3.1579 2.5030
3.0120 2.3815 3.0639 2.6762 3.0831 2.4253
2.49235468138485 2.1436 2.49235468138485 2.3159 2.5542 1.9991
2.13109025589563 2.1060 2.13109025589563 2.1555 2.3225 1.9787
2.24900295032614 2.0332 2.24900295032614 2.1780 2.5084 2.0043
2.4010 2.0438 2.5857 2.2126 2.4511 2.0329
EDIT2: Implementing RANK instead of RANK.EQ showing no difference:
I think you've got an error in your setup. My understanding is each row is meant to be a separate independent case, however your formula for calculating rank has fixed row and column references, when it should have only fixed column references. Right now, the rank for every value is being found based on the first row in your data. Instead of:
=RANK.EQ(B4,$B$4:$G$4,1)
It should be:
=RANK.EQ(B4,$B4:$G4,1)
This then alters your results in the 2nd and 3rd blocks and you should get the desired result in the 3rd block.
With the formula below in Cell B2:B4 you can filter the unique numbers in Column A.
Please note that this is an array formula so once you enter it you have to mark it and press CTRL + ALT + DEL. Hope this solves your problem. More details regarding this formula you can also find here https://exceljet.net/formula/extract-unique-items-from-a-list
Column A Column B
1
1 1 = {=INDEX($A$1:$A$5000,MATCH(0,COUNTIF($B$1:B1,$A$1:$A$5000),0))}
1 2 = {=INDEX($A$1:$A$5000,MATCH(0,COUNTIF($B$1:B2,$A$1:$A$5000),0))}
1 6 = {=INDEX($A$1:$A$5000,MATCH(0,COUNTIF($B$1:B3,$A$1:$A$5000),0))}
1
1
1
1
1
1
1
2
1
6
6
6
6
6
6
6
6
6
6
6
6
6
Try RANK instead of RANK.EQ as below. Though I am not sure whether this will work as I am testing on Excel 07.
Enter the following formula in Cell H1
=RANK(A1,$A1:$F1,1)+COUNTIF($A1:A1,A1)-1
Copy/Drag the formula down and across (to right) as required. See image for reference.
As per Microsoft Documentation on RANK.EQ function here
RANK.EQ gives duplicate numbers the same rank. However, the presence of duplicate numbers affects the ranks of subsequent numbers. For example, in a list of integers sorted in ascending order, if the number 10 appears twice and has a rank of 5, then 11 would have a rank of 7 (no number would have a rank of 6)
I've structured a formula that should spit out a numerical answer that is basically a simple sum formula with IF statements assigning numerical values to qualitative inputs. Apologies for the length, I am looking at a number of different factors.Formula is:
Cell F36 contains:
=IF(F32="Medium-High", 18, IF(F32="High", 24, SUM(F16, IF(F20="High",5,IF(F20="Medium-High",4,IF(F20="Medium",3,IF(F20="Low-medium",2,IF(F20="Low",1))))),IF(F24="High",5,IF(F24="Medium-High",4,IF(F24="Medium",3,IF(F24="Low-Medium",2,IF(F24="Low",1))))),IF(F28="High",5,IF(F28="Medium-High",4,IF(F28="Medium",3,IF(F28="Low-Medium",2,IF(F28="Low",1,IF(F28="N/A",0)))))),IF(F30="N/A",0,IF(F30="High",5,IF(F30="Medium-High",4,IF(F30="Medium",3,IF(F30="Low-Medium",2,IF(F30="Low",1)))))),IF(F32="High",5,IF(F32="Medium-High",4,IF(F32="Medium",3,IF(F32="Low-Medium",2,IF(F32="Low",1,IF(F32="N/A",0)))))))))
F16 - contains values from 1 to 5
F20, F24, F28, F30, F32 - Are dropdowns, where you choose a value: Low, Low-Medium, Medium, Medium-High, High;
Right now, based on a test input, where: F16 = 5, F20 = Low (1), F24= Medium-High (4), F28 = N/A (0), F30 = Medium (3), F32 = Medium (3) my output in F36 is 11, however doing simple adding, I should be at 5+1+4+0+3+3 = 16.
Where am I losing 5 points?
You can create a table allocating numerical output to each qualitative inputs and using vlookup to get your output. For example, for a table created on K19:L25, the following can be used:
=SUM(F16,VLOOKUP(F20,K19:L25,2,FALSE),VLOOKUP(F24,K19:L25,2,FALSE),VLOOKUP(F28,K19:L25,2,FALSE),VLOOKUP(F30,K19:L25,2,FALSE),VLOOKUP(F32,K19:L25,2,FALSE))
EDIT:
Tried your formula and it gives the correct result. Maybe your 5 in F16 is not a numerical value? You can test it by using
=ISNUMBER(F16)
and it should give a TRUE if it is a number.
Debug embedded IFs is just hell.
What you are doing is recode a 5 levels scale. You may use alternative solutions.
a. place the 5 text values (from "Low" to "High") somewhere in a sheet, say in T1:T5, even better, give this range a name
then you can retrieve the values you search with
MATCH(F20,$T$1:$T$5,0)
b. if it's suitable for your use, you may use combo boxes, presenting the 5 choices and giving the desired answer (from 1 to 5) in a linked cell.
(maybe not the answer, but I can't comment…)
(This should be a comment but I needed the formatting capabilities of an answer)
This is the current logic of your formula:
Check cell F32: "Medium-High" outputs 18, "High" outputs 24
If F32 is neither of those, then SUM the following:
F16
Lookup for F20, F24, F28, F30, and F32 where the lookup for each is:
"High" = 5
"Medium-High" = 4
"Medium" = 3
"Low-Medium" = 2
"Low" = 1
I find it strange that you first check cell F32 only to check it again later in the sum. Because this current logic produces incorrect results, we can't really advise how to fix it without sample data and expected results. My guess is you are summing too many lookups by including the F32 in there, but that's just speculation without data.