Number to the left/right on a dice? - math

I was wondering if there is a formula/trick to calculate what number is to the right or to the left on a standard 6-sided die if you know which number is on top and which is facing you.
Need it to solve a problem, but I don't feel like listing all 24 possibilities in an if-statement...:)

There aren't 24 possibilities.
From Wikipedia:
The sum of the numbers on opposite
faces is seven.
So as you already know two numbers, there are 4 possibilities left.
I'm not sure what you meant with "on the top" and "facing you", but I think you meant two neighbour faces here, so there are only 2 possibilities left as you know there opposite faces numbers, too (and those 2 possiblities only differ by the two numbers being left/right or right/left).
So, for example, using a unfolded dice, you've got "1" on the top, "2" facing you:
X
X1X
2
X
You now know that the opposite faces will be "6" (bottom) and "5" (facing away from you):
5
X1X
2
6
So there are these both possibilites:
5 5
314 413
2 2
6 6
There is only one possibility left when you know if your die is "left-handed" or "right-handed" (again, Wikipedia):
This constraint leaves one more
abstract design choice: the faces
representing 1, 2 and 3 respectively
can be placed in either clockwise or
counterclockwise order about this
vertex. If the 1, 2 and 3 faces run
counterclockwise around their common
vertex, the die is called
"right-handed"; if they run clockwise
it is called "left-handed". Standard
modern Western dice are right-handed,
whereas Chinese dice are often
left-handed
So, for the example above, the left one is a "left-handed" die, the right one is a "right-handed" die.

Opposite sides of a die always add up to 7 (at least, this is the convention).
By process of elimination you can tell what the "invisible" pair will be:
1/6
2/5
3/4
So, for every pair above, if you can see a number from it, remove it. The remaining pair is the one you are looking for.
Since there is no way to determine the "handedness" of the die, it is impossible to tell which of the pair will be to the right and which to the left.

I have no idea why this works, but:
For each pair (top/facing) there is of course only two possibilities, as both the top value and the facing value each eliminate itself and it's opposite from being left and or right: for e.g., If 1 is on the top, and a 2 is facing you, then the left and right must be either a 3 or a 4...
So for each combination, if the sum of the values is odd, and less than 7, or even and greater than 7, the lower of the two possible values is on the left and the higher is on the right.
.. and vice versa
As I am in America, I guess this rule is for a "right-handed" die, reverse it for a left-handed die.

Programattically you could do this quite easily. It is probably a little overkill (because you could use an if statement), you could also create a class such as
public class Dice {
private DiceFace[] sides = new DiceFace[]{DiceFace.ONE, DiceFace.TWO, DiceFace.THREE, DiceFace.FOUR, DiceFace.FIVE, DiceFace.SIX};
class DiceFace {
// set the face number and connecting faces...the below figures are wrong, I don't have a set of dice to check agains
static final DiceFace ONE = new DiceFace(1, 2, 3, 4, 5);
private int face;
private int northFace;
private int southFace;
private int eastFace;
private int westFace;
public DiceFace(int face, int northFace, int southFace, int eastFace, int westFace) {
// set the values
}
}
}
You could then write a method to give you the possible values for your answer by checking the dice and the values to the left and right of it.

Related

Dice numbers complemention

I want to program a dice which show me the right numbers like a real one. I know that the added numbers across from each other are 7.
But when I know 4 opposite numbers of the dice, how do I figure out where the two last one belongs?
For example:
https://de.wikipedia.org/wiki/Spielw%C3%BCrfel#/media/Datei:Craps.jpg
I know that on the top is a 6, and on the left side is 2. How do I know that on the right side is a 4 and not a 3?
Is there a possibility to figure this out without hardcode all possibilities?
Typical dice are "right-handed" (see: en.wikipedia/Dice#Construction). That is, one way to see it is:
Star with a blank cube (whatever way you'll represent it)
Pick any face, label it "1"
Move to any adjacent face, label it "2"
Turn 90º in the positive direction
positive defined by the right-hand rule, meaning rotate to the left (yes, confusing, and don't get me started on counter-clockwise... :-))
Move forward to the next face, label it "3".
Label the remaining faces by the "opposites add to 7" rule

Is there an efficient way to count dots in cells?

I have graphs of sets of points like:-
There are up to 1 million points on each graph. You can see that the points are scattered over a grid of cells, each sized 200 x 100 units. So there are 35 cells shown.
Is there an efficient way to count how many points there are in each cell? The brute force approach seems to be to parse the data 35 times with a whole load of combined is less or greater than statements.
Some of the steps below could be optimized in the sense that you could perform some of these as you build up the data set. However I'll assume you are just given a series of points and you have to find which cells they fit into. If you can inject your own code into the step that builds up the graph, you could do the stuff I wrote below along side of building the graph instead of after the fact.
You're stuck with brute force in the case of just being given the data, there's no way you can know otherwise since you have to visit each point at least once to figure out what cell it is in. Therefore we are stuck with O(n). If you have some other knowledge you could exploit, that would be up to you to utilize - but since it wasn't mentioned in the OP I will assume we're stuck with brute force.
The high level strategy would be as follows:
// 1) Set rectangle bounds to have minX/Y at +inf, and maxX/Y to be -inf
// or initialize it with the first point
// 2) For each point:
// Set the set the min with min(point.x, bounds.min.x)
// Same for the max as well
// 3) Now you have your bounds, you divide it by how many cells fit onto each
// axis while taking into account that you might need to round up with division
// truncating the results, unless you cast to float and ceil()
int cols = ceil(float(bounds.max.x - bounds.min.x) / CELL_WIDTH);
int rows = ceil(float(bounds.max.y - bounds.min.y) / CELL_HEIGHT);
// 4) You have the # of cells for the width and height, so make a 2D array of
// some sort that is w * h cells (each cell contains 32-bit int at least) and
// initialize to zero if this is C or C++
// 5) Figure out the cell number by subtracting the bottom left corner of our
// bounds (which should be the min point on the x/y axis that we found from (1))
for (Point p in points):
int col = (p.x - minX) / cellWidth;
int row = (p.y - minY) / cellHeight;
data[row][col]++;
Optimizations:
There are some ways we might be able to speed this up off the top of my head:
If you have powers of two with the cell width/height, you could do some bit shifting. If it's a multiple of ten, this might possibly speed things up if you aren't using C or C++, but I haven't profiled this so maybe hotspot in Java and the like would do this for you anyways (and no idea about Python). Then again 1 million points should be pretty fast.
We don't need to go over the whole range at the beginning, we could just keep resizing our table and adding new rows and columns if we find a bigger value. This way we'd only do one iteration over all the points instead of two.
If you don't care about the extra space usage and your numbers are positive only, you could avoid the "translate to origin" subtraction step by just assuming everything is already relative to the origin and not subtract at all. You could get away with this by modifying step (1) of the code to have the min start at 0 instead of inf (or the first point if you chose that). This might be bad however if your points are really far out on the axis and you end up creating a ton of empty slots. You'd know your data and whether this is possible or not.
There's probably a few more things that can be done but this would get you on the right track to being efficient with it. You'd be able to work back to which cell it is as well.
EDIT: This assumes you won't have some really small cell width compared to the grid size (like your width being 100 units, but your graph could span by 2 million units). If so then you'd need to look into possibly sparse matrices.

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.

Rotating between 21 positions counterclockwise?

I'm building an Arduino-based control system for a model railway turntable and I need to be able to rotate it clockwise or counterclockwise at will. I have 21 positions on the turntable, which I currently have numbered 0-20. I need to figure out how many "clicks" counterclockwise it will take to get to a given track number. How on earth can I go about finding this?
If there's a math-y way I can do it, that would be fantastic. I don't want to have an endless series of IF statements if I can avoid it.
Never mind. I found a very simple, elegant way.
Let's take my turntable for example. 21 positions, numbered 0-20.
If we are at track 0, and we have 20 tracks total, and we want to go to track 16 counterclockwise, we could do:
moves = 0 + ((20 + 1) - 16)
This yields 5, meaning if we move the turntable counterclockwise 5 tracks, we end up at track 16.
Simple, elegant, and extends to fit an infinite number of possible positions.

How to calculate a point on a circle knowing the radius and center point

I have a complicated problem and it involves an understanding of Maths I'm not confident with.
Some slight context may help. I'm building a 3D train simulator for children and it will run in the browser using WebGL. I'm trying to create a network of points to place the track assets (see image) and provide reference for the train to move along.
To help explain my problem I have created a visual representation as I am a designer who can script and not really a programmer or a mathematician:
Basically, I have 3 shapes (Figs. A, B & C) and although they have width, can be represented as a straight line for A and curves (B & C). Curves B & C are derived (bend modified) from A so are all the same length (l) which is 112. The curves (B & C) each have a radius (r) of 285.5 and the (a) angle they were bent at was 22.5°.
Each shape (A, B & C) has a registration point (start point) illustrated by the centre of the green boxes attached to each of them.
What I am trying to do is create a network of "track" starting at 0, 0 (using standard Cartesian coordinates).
My problem is where to place the next element after a curve. If it were straight track then there is no problem as I can use the length as a constant offset along the y axis but that would be boring so I need to add curves.
Fig. D. demonstrates an example of a possible track layout but please understand that I am not looking for a static answer (based on where everything is positioned in the image), I need a formula that can be applied no matter how I configure the track.
Using Fig. D. I tried to work out where to place the second curved element after the first one. I used the formula for plotting a point of the circumference of a circle given its centre coordinates and radius (Fig. E.).
I had point 1 as that was simply a case of setting the length (y position) of the straight line. I could easily work out the centre of the circle because that's just the offset y position, the offset of the radius (r) (x position) and the angle (a) which is always 22.5° (which, incidentally, was converted to Radians as per formula requirements).
After passing the values through the formula I didn't get the correct result because the formula assumed I was working anti-clockwise starting at 3 o'clock so I had to deduct 180 from (a) and convert that to Radians to get the expected result.
That did work and if I wanted to create a 180° track curve I could use the same centre point and simply deducted 22.5° from the angle each time. Great. But I want a more dynamic track layout like in Figs. D & E.
So, how would I go about working point 5 in Fig. E. because that represents the centre point for that curve segment? I simply have no idea.
Also, as a bonus question, is this the correct way to be doing this or am I over-complicating things?
This problem is the only issue stopping me from building my game and, as you can appreciate, it is a bit of a biggie so I thank anyone for their contribution in advance.
As you build up the track, the position of the next piece of track to be placed needs to be relative to location and direction of the current end of the track.
I would store an (x,y) position and an angle a to indicate the current point (with x,y starting at 0, and a starting at pi/2 radians, which corresponds to straight up in the "anticlockwise from 3-o'clock" system).
Then construct
fx = cos(a);
fy = sin(a);
lx = -sin(a);
ly = cos(a);
which correspond to the x and y components of 'forward' and 'left' vectors relative to the direction we are currently facing. If we wanted to move our position one unit forward, we would increment (x,y) by (fx, fy).
In your case, the rule for placing a straight section of track is then:
x=x+112*fx
y=y+112*fy
The rule for placing a curve is slightly more complex. For a curve turning right, we need to move forward 112*sin(22.5°), then side-step right 112*(1-cos(22.5°), then turn clockwise by 22.5°. In code,
x=x+285.206*sin(22.5*pi/180)*fx // Move forward
y=y+285.206*sin(22.5*pi/180)*fy
x=x+285.206*(1-cos(22.5*pi/180))*(-lx) // Side-step right
y=y+285.206*(1-cos(22.5*pi/180))*(-ly)
a=a-22.5*pi/180 // Turn to face new direction
Turning left is just like turning right, but with a negative angle.
To place the subsequent pieces, just run this procedure again, calculating fx,fy, lx and ly with the now-updated value of a, and then incrementing x and y depending on what type of track piece is next.
There is one other point that you might consider; in my experience, building tracks which form closed loops with these sort of pieces usually works if you stick to making 90° turns or rather symmetric layouts. However, it's quite easy to make tracks which don't quite join up, and it's not obvious to see how they should be modified to allow them to join. Something to bear in mind perhaps if your program allows children to design their own layouts.
Point 5 is equidistant from 3 as 2, but in the opposite direction.

Resources