Covering dots on a Table [closed] - math

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.

Related

Finding one coin of N in q steps

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.

Finding shortest paths to all desired points in a graph

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.

Predict the starting and end point from a sequence of points [closed]

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 10 years ago.
Improve this question
I have a sequence of points ( not vertices's ) which makes a open shape but they are randomly arranged in a array, but to effectively recognize the shape what I need to do is to arrange the points in order the shape was made.
Is there any way in which I can recognize which is the start and end point?
Edit: The points are in a 2D plane and I have the boundingbox. The points are obtained from a image processing algorithm which gives me the points from top to bottom (not in the order shape was made) as the image is processed pixel by pixel.
Given a set of points, there are various ways to reconstruct a shape from them. If you only take the distance between two points into account, then this basically boils down to a classical traveling salesman problem: you're looking for a tour through all points which minimizes the length of said tour. You could add one mor atrificial point which has the same distance to all points in the plane. That would turn a cyclic tour into a linear one: the point after that artificial point would be the starting point, and the point just before it would be the end point. There might be TSP approximation algorithms out there which can do non-cyclic tours out of the box.
Only considering distance ignores any inertia inherent to the motion of the painting device. So I don't claim that this is the best possible model. But for most models, I would still think about a way to determine the order all the points, which automatically results in identifying the start and end point. I can't think of a way to reliably identify these two without a way to order all points in between as well.
EDIT: Seems like you want to implement image segmentation instead:
Paper
Scroll down to page 28 for the mathematical description. This will give you the contours. Does that get you to where you want to be?
What you are trying to do is implement
OCR
without the use of an external library. I wouldn't recommend it for production purposes, but think it would be a great problem to tackle.
My suggestion would be to build a simple Artificial Neural Network with the image surface providing the input signals. A feed-forward, backpropagation ANN is quite easy to code, but extremely tricky to get the results you want.
You are, after all, tackling a problem that has no perfect solution yet despite many attempts. I wish you the best of luck and please keep us updated with your progress!

Least square method doesn't work as expected, or does it? [closed]

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 11 years ago.
Improve this question
I tried to improve trilateration accuracy by doing least square method. For initial estimation, I get the average value of the cluster points. This value is then increased until the distance to the next estimation is small enough. The increment value is calculated using this formula,
My question is, why most of the times the final answer diverts quite significant from what it should be? The initial estimation is even better, although not that accurate.
Do I miss something here?
Edit
The formula is as explained here. I hope this picture explains better,
See the final point is even outside the intersection area.
I think I have a clear enough idea of the problem to offer an answer.
Basically the three-cornered region's interior consists entirely of points that undershoot the three estimated distances (inaccurate circle radii). So it is not surprising that an iterative improvement to the solution, seeking a minimum squared error approximation, will move the point outside that three-cornered region.
More about why the points inside the region give distances that are below the given estimates: These points are exactly those that are inside all three circles (if such an arrangement holds). Therefore the three distances from such a point to the circles' centers are all below their respective radii.
Using the average of the three corner points (is this what is meant by cluster points in the question?) is probably a pretty good way to start. If there is a simple place to improve the calculation, it might lie in using a weighted least squares criterion rather than an absolute least squares criterion.
What I mean by this is that if one radius is 10 yards, and the other two radii are much larger (say 200 and 300 yards for the sake of discussion), it probably doesn't make sense to assume the estimated distances all have errors of about equal size (which is what an absolute least squares fit looks for). Instead assuming the error in the estimated distances is roughly proportion to each distance (a relative error criterion) is more likely to produce a better solution, e.g. giving a greater weight to the shorter distance (because a proportional error in that would be less in absolute magnitude than the proportional error in the longer distances).
This is just a sketch of one idea you might want to incorporate in your solution. I take you have only the three data to work with (locations known to fairly good accuracy as centers of circles, greater uncertainty in the three radii). So it doesn't make sense to try and apply methods that are sophisticated in respect of accuracy, but rather to prefer methods that give a robust solution. I think the relative error criterion would move you in that direction.
Least squares minimizes the overall square of the errors, but it says nothing about how close an individual point will be to the true value. The coefficients are affected by all the points, not just a few.

How to determine all line segments from a list of points generated from a mouse gesture?

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.

Resources