I'm struggling to find the right answer to the following inductive reasoning puzzles. I do not know if my reasoning is correct as the correct answer is not given afterwards.
Q3: I believe the pattern in the amount of black dots makes sure that it needs to be 2 black dots (so the most right one). What do you think?
Q7: The amount of sides that the inner figure has goes has the sequence 3, 6, 4, and is filled when the amount is uneven. That's why I went for the filled pentagon. What do you think?
Q10: I really had no idea with this one... Anyone with a logical answer?
Related
I've been given a question by my professor in Data Structures and Algorithms, and I'm having a hard time understanding how I should be answering something like this. As I've already moved on to analyzing algorithms, to be asked a question outside of the context of a pseudo-code algorithm is really messing me up.
In this video, this individual goes over the concept of Egyptian Multiplication in which you multiply numbers from one to n on the left hand side until you have enough numbers to sum to your original number. On the other side, you double your original number equally in iterations to the left hand side until you, again, have the numbers necessary on the left hand side to sum to your original left-hand number. You then take the key-value pairs only where the keys add to the original number, and sum their values to find the answer to the original question: 9 x 13.
Since I am not seeing anything at face-value, I thought I'd try to code the first part, finding the key-value pairs to have something to look at.
In python, I came up with something like the following for finding the key-vaule pairs:
def egyptian_multiplication(a, b):
result = 0
right = 1
left = b
pairs = {}
pairs[str(right)] = left
while right < a:
right = right * 2
left = left * 2
pairs[str(right)] = left
print(pairs)
egyptian_multiplication(9, 13)
OUTPUT:
{'1': 13, '2': 26, '4': 52, '8': 104, '16': 208}
Okay, so from what I can see, we're at O(n) complexity here. But now for the second part.
From a literal perspective, you need to traverse pairs.keys() as integers to find which combination adds to a, and subsequently add those associated values together. I have seen this solved in one place online not using packages that ended up being solved recursively.
The question, however, isn't to write it out in psedo-code and analyze it that way. The question is simply what is the worse case running time for Egyptian Multiplication? What are the elementary steps to solve this problem?
I'm completely thrown off by this because I'm not looking at code line by line. I need to define the elementary steps required to solve the algorithm, and then provide the worst case running time. Maybe I'm thinking too hard about this when I'm supposed to just see something at face value, but I'm not seeing it and I'm really trying my darnedest here to put this in terms that I can understand.
I have found this stack overflow question that claims they're doing Egyptian Multiplication, but it is actually detailed in the video as Russian Multiplication, so I do not believe that solves my problem.
If anyone can help me, I really am trying to understand this on my own.
I have a problem that I have a number of questions about. First, I'm mostly looking for help describing and understanding the problem at hand. Solutions are always welcome, but most importantly I could use some advice from someone more experienced than I. Now, to the problem at hand:
I have a set of orders that each require some number of items. I also have several groupings of items that each contain some number of some items (call them groups). The goal is to find a subset of the orders that can be fulfilled using as few groups as possible and where the total number of items contained within the orders is between n and N.
Edit: The constraints on the number of items contained in the orders (n and N) are chosen independently.
To me at least, that's a really complicated way of saying the problem so I've been trying to re-phrase it as a knapsack problem (I suspect this might reduce to a subset-sum). To help my conceptual understanding of this I've started using the following definitions:
First, lets say that a dimension exists for each possible item, and somethings 'length' in that dimension is the number of that particular type of item it either has or requires.
From this, an order becomes an 'n-dimensional object' where its value in each dimension corresponds to the number of that item that it requires.
In addition, a group can be seen as an 'n-dimensional box' that has space in each dimension corresponding to the number of items it provides.
An objects value is equal to the sum of its length in all dimensions.
Boxes can be combined.
Given the above I've rephrased the problem to this:
What is the smallest combination of boxes that can hold a combination of items with value between n and N.
Question #1: Is this a correct/useful way to express the problem? Does it seem like I've missed anything obvious?
As I see it, since there are two combinations that I'm looking for I need to break the problem into two parts. So far I think breaking the problem up like this is a good step:
How many objects can box (or combination of boxes) X hold?
Check all (or preferably some small subset of) the possible combinations of boxes and pick the 'best'.
That makes it a little more manageable, but I'm still struggling with the details.
Question #2: Solved To solve the first part I think it's appropriate to say that the cost of an object is equal to the sum of its length in all dimensions, so is it's value. That places me into a subset-sum problem, right? Obviously it's a special case, but does this problem have a name?
Question #3: Solved I've been looking into subset-sum solutions a lot, but I don't understand how to apply them to something like this in multiple dimensions. I assume it's been done before, but I'm unsure where to start my research. Could someone either describe the principles at work or point me in a research direction?
Edit: After looking at everyone's feedback and digging into the terms I think I've found a good algorithm I can implement to solve part 1. Since I will have a very large number of dimensions compared to the number of items it looks like using a 'primal effective capacity heuristic (PECH)' will be a good fit. I'd be interested in hearing someones thoughts about it if they have experience with such an algorithm.
Question #4: For the second part, performance is a concern and I doubt it will be realistic to brute force it. So I intend to treat all combinations of boxes as a really big tree of solutions. The idea is to compute part 1 for all combinations of M-1 boxes where M is the total number of boxes. Somehow determine the 'best' couple box combinations from that set and do the same to their child nodes on the tree. Does this sound like it would help me arrive at something close to optimal? How would I choose the 'best' box combinations?
Thanks for reading! Suggestions for edits and clarifications are welcome.
Ok, so I have this puzzle that is called the CuFrog, that consists in filling a 3x3x3 cube with a number in each position but leaping over a position when going from one to the other. For instance, considering a flattened cube, the valid position to the right of (1,1) on side 1 would be (3,1) on side 1.
So I'm using Constraints in Prolog to do this and I've given the domain of each variable (1 to 54), I've said they must all be different and that, for each position, one of the positions in the set right-left-down-up has to be the current value of such position + 1.
Also, I've given an entry point to the puzzle, which means I placed the number 1 already on the first position.
Thing is, SICStus is not finding me an answer when I'm labelling the variables. :( It seems I must be missing a restriction somewhere or maybe I'm doing something wrong. Can anyone help?
Thanks.
So you say the CLP(FD) doesn't find a solution. Do you
mean it terminates with "no" or do you mean it doesn't
terminate?
The problem looks like a Hamiltonian path problem. It
could be that the search needs exponential time, and simply
doesn't terminate in practical time.
In this particular case, giving restrictions like symmetry
breaking heuristics, could in fact reduce the search time!
For example from your starting point, you could fix the search
in 2 directions, the other directions can be derived later.
So if the answer is "No", this means too many restrictions.
If the answer is that it doesn't terminate, this means not
enough restrictions or impossible to practically solve.
Despite all the brute force you put into searching a path,
it might later turn out that a solution is systematic. Or
you might get the idea by yourself.
Bye
Given a 20x30 'sheet of graph paper' mark any even n number of cells so that every cell has an odd number of marked neighboring cells and so that all the cells connect making one 'piece'
Neighboring cells are defined as immediately adjacent cells. (All surrounding cells excluding diagonal cells).
I'm having a problem coming up with a clean algorithm. I currently have one and it's very messy and confusing and I just know there has to be a much better way to do it, I'm just not sure how. I'm looking for a quickly implemented algorithm because I don't have much time left to do the program and we have to code it in Ada which isn't a strength of mine.
I currently am making use of I made like so,
CanMark(cell); -- Checks if the cell can be marked.
HasProblem(cell); -- Checks if the cell has an even number of surrounding marked cells.
HasFix(cell); -- Checks if there is a sequence of cells that can be marked to eliminate currently existing problem.
I don't have the code with me at the moment but I will post when I get home.
Any help would be greatly appreciated.
Sorry for being unclear. I am just asking for a direction not for you to do my problem for me. I feel like this could be done using a graph related algorithm but don't know enough to know for sure. I don't have my code with me right at the moment, but I will certainly post it when I am able to.
I would start small, and build up. The smallest (n=1) is simply:
*
that clearly doesn't work since there are 0 neighbors (and even number). So no solution exists for n=1. Next, try n=2. Only one choice:
**
This works.
Now what about n=3? Doesn't work, no solution for n=3.
Now, how can you add to it to make n=4? n=6? Can you form a pattern?
Way way back (think 20+ years) I encountered a Gomoku game source code in a magazine that I typed in for my computer and had a lot of fun with.
The game was difficult to win against, but the core algorithm for the computer AI was really simply and didn't account for a lot of code. I wonder if anyone knows this algorithm and has some links to some source or theory about it.
The things I remember was that it basically allocated an array that covered the entire board. Then, whenever I, or it, placed a piece, it would add a number of weights to all locations on the board that the piece would possibly impact.
For instance (note that the weights are definitely wrong as I don't remember those):
1 1 1
2 2 2
3 3 3
444
1234X4321
3 3 3
2 2 2
1 1 1
Then it simply scanned the array for an open location with the lowest or highest value.
Things I'm fuzzy on:
Perhaps it had two arrays, one for me and one for itself and there was a min/max weighting?
There might've been more to the algorithm, but at its core it was basically an array and weighted numbers
Does this ring a bell with anyone at all? Anyone got anything that would help?
Reading your description, and thinking a little about it, I think it probably works with a single array, exactly the way you described.
To accomplish the goal of getting five-in-a-row you have to (a) prevent the opponent from succeeding and (b) succeed yourself.
To succeed yourself, you have to place stones near other stones you already have on the board, so it makes sense to add a positive score for fields next to your stones that could participate in a row. Either the linear example you gave, or something quadratic would probably work well.
To prevent your opponent from succeeding, you have to place stones next to his / her stones. It's especially good if you strike two birds with a single stone, so opponent's stones should increase the value of the surrounding fields the same way yours do -- the more stones he already has lined up, the higher the score, and the more likely the algorithm will try to cut the opponent off.
The most important thing here is the weighting of the different fields, and whether the opponent's stones are weighted differently than yours. Unfortunately I can't help with that, but the values should be reasonably simple to figure out through trial and error once the game itself is written.
However this is a very basic approach, and would be outperformed by a tree search algorithm. Searching Google, there's a related paper on Threat search, which apparently works well for Gomoku. The paper is behind a pay-wall though :/
I haven't read the article, but from the description my guess would be some form of the Minimax algorithm
I saw this algorithm you mentioned - it was pretty simple and fast (no backtracking :-)) and it played very well :-) I must have the source somewhere but it is a lot years ago... There were weights for your stones depending on how much of other stones were near, and weights of oponent stones. These were lower so the algorithm preferred the attacking strategy.
But this is of course very trivial algorithm. Winning strategy has been already found.
See this paper: L. Victor Allis, H. J. van den Herik, M. P. H. Huntjens. Go-Moku and Threat-Space Search. It helped me a lot when I was writting my own program. This way you'll be able to write program which is very good in attacking the opponent and finding winning combinations.
It's an ancient game - I found the code on Planet Source Code. I played this game during college and in 286 days had a BASIC version of it.
Here is the program you are looking for
ftp://ftp.mrynet.com/USENIX/80.1/boulder/dpw/gomoku.c
It is almost 40 years old
Working on an open source version for iPhone.
Hit me up if interested in joining!
https://github.com/kigster/kigomoku