Set the task about dice, tried to solve, it didn’t work out. Help me please.
Throw one dice. If 2 falls, we get 2 coins, if 3 - 3 coins, etc. to 6. If 1 falls, the game ends. How much can you earn on average per game?
My attempt to solve - 2*1/6 + 3*1/6 + 4*1/6 + 5*1/6 + 6*1/6.
Also I thought about (2+3+4+5+6)*5/6, but i don't know if that is correct
Related
In a crossover fantasy universe, houin kyoma is up in a battle against powerful monster nomu that can kill him in a single blow. However being a brilliant scientist kyoma found a way to pause time for exactly M seconds. Each second, kyoma attacks nomu with certain power, which will reduce his health points by that exact power Initially nomu had H health points. Nomu dies when his health points reach 0, Normally kyoma performs normal attack with power A. Besides from kyomas brilliance, luck plays a major role in events of this universe. Kyoma luck L is defined as probability of performing a super attack. A super attack increases power of normal attack by C. Given this information calculate and print the probability that kyoma kills nomu and survives. If kyoma dies print RIP.
Input format
First line is integer T denoting number test cases.
Each test case consist of single line with space separated number A H L1 L2 M C. Where luck L is defined as L1/L2. Other number are, as described above
Output
Print probability that kyoma kills nomu in form p1/p2 where p1<=p2 and gcd(p1,p2)=1. If impossible, print RIP without quotes
Example
input
1
10 33 7 10 3 2
Output
98/125
How the probability comes to 98/125?
You have 3 seconds ==> 3 attacks.
Monster has 33 health points.
Normal attack does 10 damage.
Super attack does 12 damage.
==> In order to kill the monster you need to get lucky at least twice out of three attacks.
The probability of super attack is 7/10, the probability of standard attack is 3/10.
Let's check the variants:
If first attack is not lucky, the other 2 must be lucky.
If first attack is lucky, only one of the remaining 2 must be lucky.
==> Probability to kill the monster = 3/10*7/10*7/10+7/10*(3/10*7/10+7/10) = 98/125
I am trying to solve an extension of Assignment problem, where both tasks and the man hours are divisible.
for instance, a man X has 4 hours available in a day, can do 1/3 of task A in 2 hours, 1/4 of task B in 4 hours. Man Y has 10 hours available can do 1/5 of a task A in 1.3 hours, 1/8 of task B in 6 hours. Is there an extension of BiPartite matching which can solve this?
Thanks!
I don't think that you can easily model this as a bipartite matching. However, it should be fairly easy to create a linear program for your problem. Just have for every worker a set of variables x_{i,j} which indicates how much of person i's time is allocated to task j.
Let h_i be the number of hours available for person i. Then, for every person i it must hold that
Let a_{i,j} be the "efficiency" of person i at task j, i.e., how much of the task the person can do in one hour. Then, for every task j it must hold that:
That's it. No integrality constraints or anything.
I have come across two dynamic programming problems. One of the problems is
What is the number of possible ways to climb a staircase with n steps given that I can hop either 1 , 2 or 3 steps at a time.
The Dynamic programming approach for solving this problem goes as follows.
If C(n) is number of ways of climbing the staircase, then
C(n) = C(n-1) + C(n-2) + C(n-3) .
This is because , if we reach n-1 stairs, we can hop to n by 1 step hop or
if we reach n-2 stairs, we can hop to n by 2 step hop or
if we reach n-3 stairs, we can hop to n by 3 step hop
As I was about to think, I understood the above approach, I came across the coin change problem which is
What is the number of ways of representing n cents, given infinite number of 25 cent coins, 10 cent coins (dimes), 5 cent coins(nickels) and 1 cent coins
It turns out the solution for this problem is not similar to the one above and is bit complex. That is ,
C(n) = C(n-1) + C(n-5) + C(n-10) + C(n-25) is not true. I am still trying to understand the approach for solving this problem. But my question is How is the coin change problem different from the much simpler climbing steps problem?
In the steps problem, the order matters: (1,2) is not the same as (2,1). With the coin problem, only the number of each type of coin used matters.
Scott's solution is absolutely correct, and he mentions the crux of the difference between the two problems. Here's a little more color on the two problems to help intuitively understand the difference.
For Dynamic Programming problems that involve recursion, the trick is to get the subproblem right. Once the subproblem is correct, it is just a matter of building on top of that.
The Staircase problem deals with sequences so the subproblem is easier to see intuitively. For the Coin-change problem, we are dealing with counts so the subproblem is around whether or not to use a particular denomination. We compute one part of the solution using a denomination, and another without using it. That is a slightly more difficult insight to see, but once you see that, you can recursively compute the rest.
So here's one way to think about the two problems:
Staircase Sequence
Introduce one new step. The nth step has been added. How do we compute S[N]?
S[N] = S[N-1] + S[N-2] + S[N-3]
Coin Change
Introduce a new small coin denomination. Let's say a coin of denomination 'm' has newly been introduced.
How do we now compute C[n], knowing C[N, with all coins except m]?
All the ways to reach N without coin m still hold. But each new coin denomination 'm' fundamentally changes the ways to get to N. So to compute C[N using m] we have to recursively compute C[N-m, using the new coin m], and C[N-2m using m]...and so on.
C[N, with m] = C[N, without m] + C[N-m, with m]
Hope that helps.
I was going to meet with my TA today but just didn't have the time. I am in an algorithms analysis class and we started doing recurrence relations and I'm not 100% sure if I am doing this problem correct. I get to a point where I am just stuck and don't know what to do. Maybe I'm doing this wrong, who knows. The question doesn't care about upper or lower bounds, it just wants a theta.
The problem is this:
T(n) = T(n-1) + cn^(2)
This is what I have so far....
=T(n-2) + (n-1)^(2) + cn^(2)
=T(n-3) + (n-2)^(2) + 2cn^(2)
=T(n-4) + (n-3)^(2) + 3cn^(2)
So, at this point I was going to generalize and substitute K into the equation.
T(n-k) + (n-k+1)^(2) + c(K-1)^(2)
Now, I start to bring the base case of 1 into the picture. On a couple of previous, more simple problems, I was able to set my generalized k equation equal to 1 and then solve for K. Then put K back into the equation to get my ultimate answer.
But I am totally stuck on the (n-k+1)^(2) part. I mean, should I actually foil all this out? I did it and got k^(2)-2kn-2k+n^(2) +2n +1 = 1. At this point I'm thinking I totally must have done something wrong since I've never see this in previous problems.
Could anyone offer me some help with how to solve this one? I would greatly appreciate it.
What you have isn't fully correct even at the first line of "what I have so far".
Go ahead and do the full substitutions, to see that:
T(n-1) = T(n-2) + c(n-1)^2
so
T(n) = T(n-2) + c(n-1)^2 + c(n)^2
T(n) = T(n-3) + c(n-2)^2 + c(n-1)^2 + c(n)^2
Overall running time looks like adding "c(n-i)^2" for each value of i from 0 to your base case. Hopefully that puts you on the right track.
I am looking at whether or not certain 'systems' for betting really do work as claimed, namely, that they have a positive expectation. One such system is based on the rebate on loss. You basically have a large master pot, say $1 million. Your bankroll for each game is $50k.
The way it works is as follows:
Start with $50k, always bet on banker
If you win, add the money to the master pot. Then play again with $50k.
If you lose(now you're at $30k) play till you either:
(a) hit 0, you get a rebate of 10%. Begin playing again with $50k+5k=$55k.
(b) If you win more than the initial bankroll, add the money to the master pot. Then play again with $50k.
Continue until you double the master pot.
I just can't find an easy way of programming out the possible cases in R, since you can eventually go down an improbable path.
For example, you start at 50k, lose 20, win 19, now you're at 49, now you lose 20, lose 20, now you're at 9, you either lose 9 and get back 5k or you win and this cycle continues until you either end up with more than 50k or hit 0 and get the rebate on the 50k and start again with $50k +5k.
Here's some code I started, but I haven't figured out a good way of handling the cases where you get stuck and keeping track of the number of games played. Thanks again for your help. Obviously, I understand you may be busy and not have time.
p.loss <- .4462466
p.win <- .4585974
p.tie <- 1 - (p.win+p.loss)
prob <- c(p.win,p.tie,p.loss)
bet<-20
x <- c(19,0,-20)
r <- 10 # rebate = 20%
br.i <- 50
br<-200
#for(i in 1:100){
# cbr.i<-0
y <- sample(x,1,replace=T,prob)
cbr.i<-y+br.i
if(cbr.i > br.i){
br<-br+(cbr.i-br.i);
cbr.i<-br.i;
}else{
y <- sample(x,2,replace=T,prob);
if( sum(y)< cbr.i ){ cbr.i<-br.i+(1/r)*br.i; br<-br-br.i}
cbr.i<-y+
}else{
cbr.i<- sum(y) + cbr.i;
}if(cbr.i <= bet){
y <- sample(x,1,replace=T,prob)
if(abs(y)>cbr.i){ cbr.i<-br.i+(1/r)*br.i } }
The way you've phrased to rules don't make the game entirely clear to me, but here's some general advice on how you might solve your problem.
First of all, sit down with pen and paper, and see if you can make some progress towards an analytic solution. If the game is sufficiently complicated, this might not be possible, but you may get some more insight into how the game works.
Next step, if that fails, is to run a simulation. This means writing a function that accepts a starting level of player cash, and house cash (optionally this could be infinite), and a maximum number of bets to place. It then simulates playing the game, placing bets according your your betting system until either
i. The player goes broke
ii. The house goes broke
iii. You reach the maximum number of bets. (You need this maximum so you don't get stuck simulating forever.)
The function should return the amount of cash that the player has after all the bets have been placed.
Run this function lots of times, and compare the end cash with the starting cash. The average of end cash / start cash is a measure of your expectation.
Try the simulation with different inputs. (For instance, with many gambling games, even if you could theoretically make an infinite amount of money in the long run, stochastic variation means that you go broke before you get there.)