Subject: Finding One Coin of 13 in 3 Steps
There is a pile of thirteen coins, all of equal size. Twelve are of
equal weight. One is of a different weight. In three weighings(using scales) find
the unequal coin and determine if it is heavier or lighter.
I scratched my head on this one. I have found an answer but about 12.
Is it possible to do for 13 ?
So if it is possible can we end up with a method that can calculate the number of steps that are needed to find the unequal coin in pile of N. Pseudocode is just fair enough.
NOTE: Do not forget we do not know if the coin is lighter or heavier.
PS: Solution for 12 and some interesting thoughts here.
No, we cannot find a method that is guaranteed to determine which coin is not equal to the others and if it is heavier or lighter then the others, not with the restrictions you lay out.
One weighing of coins has three possible results: left pan down and right pan up (so the total of weights on the left is greater than the total of weights on the right), left pan up and right pan down (so the total of weights on the left is less than the total of weights on the right), or the pans balance (so the total of weights on the left is equal to the total of weights on the right). If we want to distinguish between four or more possibilities with just one weighing, we may fail since we can guarantee only three. Similarly, two weighings can distinguish between at most nine possibilities, and three weighings can handle at most 27 possibilities. The problem has 13 coins, each of which may be light or heavy, so there are 26 possibilities to begin. It looks like we may be able to handle them.
However, the problem comes at the first weighing. What happens if we place four or fewer weights on each pan? If one side goes up, all we know is that the special coin is among the five or more coins we did not use. However, that is 10 possibilities: light or heavy, for five coins. Therefore two more weighings is not guaranteed to distinguish between them.
Now, what happens if we place five or more weights on each pan for the first weighing? If the left pan rises, either one of the five or more weights on the left is light or one of the five or more weights on the right is heavy. That is at least 10 possibilities, so two more weighings is not guaranteed to distinguish between them.
Either way we may end up with 10 or more possibilities to solve in two weighings, which spoils any solution. Any method that has only three possible results at each step will need to be more sophisticated than the weighing pans.
Related
I have an experiment where we are going to plant 4 different bushes in two different sized square plantings (8x8 bushes and 12x12 bushes) and we want their placement in the plantings to be randomized. I thought of trying to create a matrix in R for this purpose, since it's the software I'm used to. The issue is that the randomization has to follow a few limitations, and I’m not that experienced in creating matrices. The limitations are:
There has to be one of each species in each corner of the planting.
The two outer rows in the square has to contain an equal amount of each species.
The inner 4x4 quadrant in the square has to contain an equal amount of each species.
Plants of the same species can’t be planted next each other, but if they are placed on the diagonal of each other it’s fine.
I hope the issue is clear, otherwise ask!
I was asked the following question in an interview
You are given a 4 X 4 grid. Some locations on the grid contain
treasure. Your task is the visit all the locations that contain the
treasure and collect it. You are allowed to move on the four adjacent
cells (up, down, left, right). Each movement and the action of
"treasure collection" is of a single unit cost. You need to traverse
the entire grid, and collect all the treasure on the grid, minimizing
the cost taken.
If I can recall properly, here is a sample graph that was given:
U..X
..X.
X..X
..X.
Where, U is my current position and X marks the position of the treasure.
The solution that I presented was to use breadth first search traversing the graph and "collecting the treasure" while doing so. However, the interviewer insisted that there was a better way to minimize the cost. I hope you could help me in figuring it out.
You should have recognized that this is a Traveling Salesman Problem in a small disguise. Using breadth-first, you can determine the shortest way between the different vertices you have to visit which gives you a derived graph containing just those ways as weighted edges between the vertices. From then on, it's a classic TSP.
BFS alone is not going to solve it for you, because you cannot move in all directions at the same time. It is not a single-source shortest path problem, because once you collect the treasure, you start your path to the next one from your current spot, not from the original spot.
The time that it takes to collect all treasure depends on the order in which you visit the boxes with X. Since there are only five of them, you can try all 120 orderings, compute the cost, and pick the best one.
Note that if the order is fixed, the solution is trivial: you add up manhattan distances between the cells in order, and pick the smallest result.
I work for game development company which makes casual games. One of the main casual genres is match-3: there is a field and chips of different colors. One should move chips so that they make lines of at least three chips of the same color. If the move leads to making a line the chips in the line disappear.
Chips on field can be located differently: there may be a lot of chips of the same color gouped in one place or there may be a situation when a player can't make a move - all the neighbour chips are of the different colors.
So, I want to express the situation on the field mathematically with a factor of order (disorder). If the factor is high a player can make a lot of matches and the lines made by the player are long. If the factor is low, the field is in complete disorder and one can't make a single match. This may be helpful for generating field of different difficulty.
The question is: what branch of math can help me to do this. Where should I start my research. Any suggestions for keywords to google?
Thanks in advace.
Entropy.
I would look into graph theory. You can for example make a graph, where nodes would be positions on the board, and two nodes would be connected with an edge if they are neighbours and have a chip of the same color. If you have large components with nodes of large degree, you have less disorder. If all your components are small, you have high disorder.
First thing that comes to mind is that you're looking at the distribution of n populations (one for each color), which I would approach with Poisson sampling,. You can use that to calculate the probability of finding two adjacent units of the same population (color), which will give you a measure of the difficulty of your puzzle.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
In the Communications of the ACM, August 2008 "Puzzled" column, Peter Winkler asked the following question:
On the table before us are 10 dots,
and in our pocket are 10 $1 coins.
Prove the coins can be placed on the
table (no two overlapping) in such a
way that all dots are covered. Figure
2 shows a valid placement of the coins
for this particular set of dots; they
are transparent so we can see them.
The three coins at the bottom are not
needed.
In the following issue, he presented his proof:
We had to show that any 10 dots on a
table can be covered by
non-overlapping $1 coins, in a problem
devised by Naoki Inaba and sent to me
by his friend, Hirokazu Iwasawa, both
puzzle mavens in Japan.
The key is to note that packing disks
arranged in a honeycomb pattern cover
more than 90% of the plane. But how do
we know they do? A disk of radius one
fits inside a regular hexagon made up
of six equilateral triangles of
altitude one. Since each such triangle
has area sqrt(3)/3, the hexagon
itself has area 2*sqrt(3); since the
hexagons tile the plane in a honeycomb
pattern, the disks, each with area π,
cover π /(2*sqrt(3)) ~ .9069 of the
plane's surface.
It follows that if the disks are
placed randomly on the plane, the
probability that any particular point
is covered is .9069. Therefore, if we
randomly place lots of $1 coins
(borrowed) on the table in a hexagonal
pattern, on average, 9.069 of our 10
points will be covered, meaning at
least some of the time all 10 will be
covered. (We need at most only 10
coins so give back the rest.)
What does it mean that the disks cover
90.69% of the infinite plane? The easiest way to answer is to say,
perhaps, that the percentage of any
large square covered by the disks
approaches this value as the square
expands. What is "random" about the
placement of the disks? One way to
think it through is to fix any packing
and any disk within it, then pick a
point uniformly at random from the
honeycomb hexagon containing the disk
and move the disk so its center is at
the chosen point.
I don't understand. Doesn't the probabilistic nature of this proof simply mean that in the majority of configurations, all 10 dots can be covered. Can't we still come up with a configuration involving 10 (or less) dots where one of the dots can't be covered?
I think that I can re-arrange Winkler's argument to make it a little more convincing.
You're given an arrangement of dots on a table. You also have a big template made of coins glued together in a honeycomb pattern. You now do a Monte Carlo simulation, repeatedly throwing the honeycomb on the table at a random location (but always with the same orientation), and counting the number of covered dots. If you get enough samples you will eventually find that the expected average number of dots covered is 9.069 per throw.
The key insight is that if the average is 9.069, there must have been a throw where 10 dots were covered. Because if you never covered 10 dots, the average would be 9 or less.
So now you know that there was at least one throw that covered 10 dots. You duplicate that throw, and remove all the coins that aren't covering a dot. There will be 10 or fewer coins remaining.
A small digression: Is it possible that for some clever arrangement of dots the long range average of covered dots is something other than 9.069? The answer is no, because each of the dots can be considered separately. In other words, in 10000 throws of the honeycomb, the expected number each dot will be covered is 9069 times. So we expect a total of 90690 dots to be covered, for an average of 9.069 per throw.
Currently I am interning at a software company and one of my tasks has been to implement the recognition of mouse gestures. One of the senior developers helped me get started and provided code/projects that uses the $1 Unistroke Recognizer http://depts.washington.edu/aimgroup/proj/dollar/. I get, in a broad way, what the $1 Unistroke Recognizer is doing and how it works but am a bit overwhelmed with trying to understand all of the internals/finer details of it.
My problem is that I am trying to recognize the gesture of moving the mouse downards, then upwards. The $1 Unistroke Recognizer determines that the gesture I created was a downwards gesture, which is infact what it ought to do. What I really would like it to do is say "I recognize a downards gesture AND THEN an upwards gesture."
I do not know if the lack of understanding of the $1 Unistroke Recognizer completely is causing me to scratch my head, but does anyone have any ideas as to how to recognize two different gestures from moving the mouse downwards then upwards?
Here is my idea that I thought might help me but would love for someone who is an expert or even knows just a bit more than me to let me know what you think. Any help or resources that you know of would be greatly appreciated.
How My Application Currently Works:
The way that my current application works is that I capture points from where the mouse cursor is while the user holds down the left mouse button. A list of points then gets feed to a the gesture recognizer and it then spits out what it thinks to be the best shape/gesture that cooresponds to the captured points.
My Idea:
What I wanted to do is before I feed the points to the gesture recognizer is to somehow go through all the points and break them down into separate lines or curves. This way I could feed each line/curve in one at a time and from the basic movements of down, up, left, right, diagonals, and curves I could determine the final shape/gesture.
One way I thought would be good in determining if there are separate lines in my list of points is sampling groups of points and looking at their slope. If the slope of a sampled group of points differed X% from some other group of sampled points then it would be safe to assume that there is indeed a separate line present.
What I Think Are Possible Problems In My Thinking:
Where do I determine the end of a line and the start of a separate line? If I was to use the idea of checking the slope of a group of points and then determined that there was a separate line present that doesn't mean I nessecarily found the slope of a separate line. For example if you were to draw a straight edged "L" with a right angle and sample the slope of the points around the corner of the "L" you would see that the slope would give resonable indication that there is a separate line present but those points don't correspond to the start of a separate line.
How to deal with the ever changing slope of a curved line? The gesture recognizer that I use handles curves already in the way I want it too. But I don't want my method that I use to determine separate lines keep on looking for these so called separate lines in a curve because its slope is changing all the time when I sample groups of points. Would I just stop sampling points once the slope changed more than X% so many times in a row?
I'm not using the correct "type" of math for determining separate lines. Math isn't my strongest subject but I did do some research. I tried to look into Dot Products and see if that would point me in some direction, but I don't know if it will. Has anyone used Dot Prodcuts for doing something like this or some other method?
Final Thoughts, Remarks, And Thanks:
Part of my problem I feel like is that I don't know how to compeletly ask my question. I wouldn't be surprised if this problem has already been asked (in one way or another) and a solution exist that can be Googled. But my search results on Google didn't provide any solutions as I just don't know exactly how to ask my question yet. If you feel like it is confusing please let me know where and why and I will help clarify it. In doing so maybe my searches on Google will become more precise and I will be able to find a solution.
I just want to say thanks again for reading my post. I know its long but didn't really know where else to ask it. Imma talk with some other people around the office but all of my best solutions I have used throughout school have come from the StackOverflow community so I owe much thanks to you.
Edits To This Post:
(7/6 4:00 PM) Another idea I thought about was comparing all the points before a Min/Max point. For example, if I moved the mouse downards then upwards, my starting point would be the current Max point while the point where I start moving the mouse back upwards would be my min point. I could then go ahead and look to see if there are any points after the min point and if so say that there could be a new potential line. I dunno how well this will work on other shapes like stars but thats another thing Im going to look into. Has anyone done something similar to this before?
If your problem can be narrowed down to breaking apart a general curve into straight or smoothly curved partial lines then you could try this.
Comparing the slope of the segments and identifying breaking points where it is greater then some threshold would work in a very simplified case. Imagine a perfectly formed L-shape where you have a right angle between two straight lines. Obviously the corner point would be the only one where the slope difference is above the threshold as long as the threshold is between 0 and 90 degrees, and thus a identifiable breaking point.
However, the vertical and horizontal lines may be slightly curved so the threshold would need to be large enough for these small differences in slope to be ignored as breaking points. You'd also have to decide how sharp a corner the algorithm should pick up as a break. is 90 deg or higher required, or is even 30 deg enough? This is an important question.
Finally, to make this robust I would not be satisfied comparing the slopes of two adjacent segments. Hands may shake, corners may be smoothed out and the ideal conditions to find straight lines and sharp corners will probably never occur. For each point investigated for a break I would take the average slope of the N previous segments and compare it to the average slope of the N following segments. This can be efficiently implemented using a running mean. By choosing a good sample number N (depending on the accuracy of the input, the total number of points, etc) the algorithm can avoid the noise and make better detections.
Basically the algorithm would be:
For each investigated point (beginning N points into the sequence and ending N points before the end.)
Compute average slope of the N previous segments.
Compute average slope of the N next segments.
If the difference of the averages is greater than the Threshold, mark current point as a breaking point.
This is quite off the top of my head. You'd have to try it in your application.
if you work with absolute angles, like upwards and downwards, you can simply take the absolute slope between two points (not necessarily adjacent) to determine if it's RIGHT, LEFT, UP, DOWN (if that is enough of a distinction)
the art is to find a distance between points so that the angle is not random (with 1px, the angle will be a multiple of 45°)
There is a firefox plugin for Navigation using mouse gestures that works very well. I think it's FireGestures, but I'm not sure. I guess you can get some inspiration from that one
Additional thought: If you draw a shape by connectiong successive points, then connecting back to the first point, the ratio between the area and the final line segment's length is also an indicator for the gesture's "edginess"
If you are just interested in up/down/left/right, a first approximation is to check 45 degree segments of a circle. This is easily done by checking the the horizontal difference between (successive) points against the vertical difference between points.
Say you have a greater positive horizontal difference than vertical difference, then that would be 'RIGHT'.
The only difficulty then comes for example, in distinguishing UP/DOWN from UP/RIGHT/DOWN. But this could be done by distances between points. If you determine that the mouse has moved RIGHT for less than 20 pixels say, then you can ignore that movement.