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
We have rectangle sheet, and a small rectangle piece cut inside it at RANDOM place. How to make make that sheet into exact same 2 halves?
If you do a cut through the center of a rectangle, no matter at what angle, this rectangle will be divided in half.
Thus, if we make a cut through the center of the cutout rectangle, each side of the cut will have 50% of the cutout area. And if we -- at the same time -- cut through the center of the large rectangle, this should do it. Both sides of the cut have half the area of the large rectangle, minus half the size of the cutout.
Of course, that is if by "exact same 2 halves" you mean same area, but not necessarily same shape. The latter will generally not be possible.
re: folding - will not work because you could easily end up with more than two parts cutting folded rectangle.
I would try brute-force approach. If the hole is co-oriented to large rectangle, you can cut along one of the edges and have only three cases to check: 1 try to cut above the hole - if it's not possible to end with same area halves, try to 2 cut through the hole - if it's still not possible, 3 cut below the hole will certainly do it. the code for 1 and 3 would be very similar, btw. all 3 cases are simple linear equations for the height of cut. For example, 1:
+----W---+
d |
+--------+
| |
| +-w-+ |
H h | |
| +---+ |
| |
| |
+--------+
We have d * W = (H - d) * W - h * w
If d from this equation is not above the hole, go to case 2, and so on.
After a lot of thought, I think this is the correct answer.
We have to fold the paper sheet, many times, so that it should form the rectangle of the small rectangle area.
If we cut the folded one, it should give 2 equal parts definitely.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I got the orange rectangle below from the black points and their coordinates, I'd like to straighten up that rectangle just like the green one, is there an equation for this? (I always want the long side to be at the bottom)
Yes, it's a simple 2D rotation:
P' = T*P
where
| cos(theta) -sin(theta) |
T = | |
| sin(theta) cos(theta) |
The signs I chose assume positive theta (in radians, of course) means a counterclockwise rotation using the right hand rule with the z-axis pointing out of the page. A clockwise rotation, as shown in your diagram, would be the transpose of the matrix: switch the signs of the off-diagonal sine terms.
I am trying to create a screen overlay for an existing computer game. This overlay should display icons that show certain locations in the 3D world. Now because I do not have access to the data I want to be able to get the screen positions, I have to figure it out using the following variables:
Player position (x,y,z)
Camera position (x,y,z)
Point position (x,y,z)
Camera Angle(FOV)
Using these variables I managed to get the right and left edge of the camera view. Using these 2 variables I am able to get the point between 0 and 1 where the icon should be displayed on the x axis. (0 is on the left edge, 1 is right edge) This seems to work quite well, but only if I am aligned to either the X or Z axis, as shown in the following example: http://i.imgur.com/OIZWBME.png
The problem is, I have no clue on how to make this work when the camera rotates. I've tried combining the 2 points that work alone, but also with other variables like the camera-player world rotation and angles.
Does anyone have any ideas on how I might be able to make this work? If I forgot to supply any info please let me know!
Tim
There are pretty good articles on wikipedia (https://en.wikipedia.org/wiki/3D_projection), and other tutorials online (http://www.codeproject.com/Articles/2158/A-short-discussion-on-mapping-3D-objects-to-a-2D-d).
Essentially, for this simple instance, it boils down to rotating everything in a virtual space before rendering. The points you want to draw are moved in relation to the camera position, so that the camera becomes the new axis point, and then you can draw as before.
A simple top down ascii-art example:
( []< is the camera, a, b, and c are points)
What you can already draw:
^ <-----y------>
|
| b
| []< a
x
| c
|
|
v
What you can't draw: (the camera moved and rotated)
<-----y------>
^ [ ]
| ^
| b
x a
| c
|
v
So you need to map (usually using matrixies) the camera's global position against the positions of everything else, so that you end up with:
After transformation:
<---------fake y------>
^
| a
|
fake | b
x: | []<
| c
|
v
Which you can now draw as normal. I'm not an expert on this, but does this help to get you started?
here's a question that's been bothering me for the last couple of days - my colleague believes this is a well-researched problem, but I couldn't find any papers online (perhaps the key words I used were incorrect).
Given a graph where each vertex corresponds to a surface and an edge exists between two vertices if the corresponding surfaces meet at a line, how would I go about identifying the surfaces that combine to form closed volumes?
So for instance, the adjacency list for a cube (with surfaces numbered 1 to 6) might look something like this:
1 -> [4,2,5,6]
2 -> [1,3,5,6]
3 -> [2,4,5,6]
4 -> [3,1,5,6]
5 -> [1,2,3,4]
6 -> [1,2,3,4]
In addition to this information, I also know if some surfaces have free-edges (i.e those edges are not shared with any other surface) which means I can immediately exclude these surfaces since a surface with a free-edge cannot be part of a cavity boundary. Also, if two surfaces meet, they will meet cleanly at a boundary - no glancing blows etc.
What I hope to be able to do is not just identify that a cavity exists but also to output a mapping between surfaces and the cavities they contain. For instance, in the case of two cubes which meet at an edge (not enough reputation to post an image, so here's a side view):
-----------
| |
| |
| |
---------------------
| |
| |
| |
-----------
...this would be the desired output assuming surfaces 1-6 make up cube ONE and 7-12 make up cube TWO:
Volume 1 -> [1,2,3,4,5,6]
Volume 2 -> [7,8,9,10,11,12]
Note that, in this case, some surfaces have SIX neighbors in the graph while others have only FOUR neighbors.
Any help would be much appreciated!
Yes, this area is known as computational topology. Its central objects are algebraic groups of loops known as homology groups (H1 when loops are formed by 1-dim edges and H2 when we talk about 2-dim faces).
One can analyze such group by forming a homology group matrix. For some queries both H1 and H2 matrices are needed.
When matrix can be re-arranged into independent blocks it means shapes are not interacting. When a single-block homology matrix has ranking N it means shape has N cavities (holes). Simple shape like cube has 0 holes, torus has 1,etc.
One can find C++ and MATLAB open-source packages for these computations.
Hope it gives some helpful keywords.
I have found something NOT funny with rectangles:
Lets say, given are values of left, top, right and bottom coordinates and all those coordinates are intended to be inclusive.
So, calculating the width goes like:
width = right - left + 1
So far, so logical. But!
A width of zero (which makes sense, sometimes) would have to be stored as:
right = left - 1
which makes problems, when it comes to the following operations:
Sorting the rectangle coordinates (to make it go left to right, top to bottom)
Looping
Ok, of course those things can be handled with extra code for the special case of Width == 0, but, seriously, is there no better solution, no standard pattern or best practice to handle this?
Edit:
For the time being I have abandoned the "sorting" of the coordinates in my code and replaced it with an assertion stating that the rectangle must be left -> right, up -> down, but seriously...
To address this problem, most graphics libraries will draw rectangles from the left coordinate up to but not including the right coordinate. So if left=10 and right=20, then the ten pixels 10 through 19 will be drawn.
You can think of this as the pixel coordinate referring not to the lit-up portion, but the grid lines between pixels.
+---+---+---+
| | | |
+---+---+---+
| | | |
+---+---+---+
^ ^ ^ ^
0 1 2 3
It's important to distinguish between coordinates and pixels. You can think of the coordinate system as being an invisible grid which runs between pixels. Thinking of coordinates this way if you define a rect as { 0, 3, 0, 5 }, then you get 3 pixels by 5 pixels as expected.
| | | | | |
0 -x--+--+--+--+--x-
| | | | | |
1 -+--+--+--+--+--+-
| | | | | | <- pixels are rectangular areas between coordinate grid
2 -+--+--+--+--+--+-
| | | | | |
3 -x--+--+--+--+--x-
| | | | | |
0 1 2 3 4 5
If the edges (left, right, top, bottom) are inclusive then, by definition, the width (and height) of the rectangle cannot be 0. By "including" the side (which is a pixel), you're saying that it has to be at least 1 pixel wide.
Saying that
all those coordinates are intended to be inclusive
means that there actually are two distinct rectangles, one within another. That's where you get caught: when you write
width = right - left + 1
it really means:
inner_width = outer_right - outer_left + thickness
where thickness is the distance between corresponding sides of inner and outer rectangles.
So, to deal with the problem in abstract mathematical sense, you have to consider two rectangles instead of one.
Of course you can find a workaround for this, but what really is the problem here is going out of scope.
Your scope is a rectangle, and even if a width of zero would come in handy : there is no such thing as a rectangle with width zero.
Normally all functions have contracts and a predcondition of a functions that says docalculation(par_rectangle) is that par_rectangle in fact is a rectangle.
If you need a retangle-like object wich can be width zero, you first need to define it waterproof, and never just assert that rules for rectangles will apply on your definiton.
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.