suppose the cave system contains 100 caves, of which 90 caves are without a hidden treasure and 10 caves contain a buried gold object. In 70% of the caves with a hidden treasure, the Wumpus has left behind his usual stench from digging about and bumping into walls. In the remaining caves with hidden treasures in them, the Wumpus has left no trace, i.e. they are non-smelly. Furthermore, all the caves without a hidden treasure are free from smell, since the Wumpus has fled the cave system. The agent is now located in a random cave and can perceive that it is not smelly. What is the probability that this cave contains a hidden treasure?
how can I solve this using Bayes formula?
prob. of cave buried treasure = 10/100.
prob. of cave Hidden treasure = 0.7
*HT- stands for Hidden treasure
p(HT/Cave) = (1/100*10/100)/(1/100*70/100*29/100*1/100)
i have found the solution but i am not sure it is right or not ? can anyone help me?
You want to know what's the probability of finding a hidden treasure if the cave is not smelly. So you want to calculate P(HT|notsmelly). Using Bayes' theorem that would be:
According to your data,
P(notsmelly|HT) = 0.3 and P(HT) = 0.1
P(notsmelly) is given by the 90 empty caves plus the 30% of the 10 treasured caves. So that would be 0.93.
So your probability should be (0.3 x 0.1)/0.93 = 0.0322 which is about 3%.
Let π΅ denote the event that the caves without a hidden treasure.
Let π denote the event that there is a treasure.
Now apply Bayes rule on π(π|π΅)=π(π)π(π΅|π)/π(π΅)=(π(π)π(π΅|π))/(π(π)π(π΅|π)+π(ππ)π(π΅|ππ)).
Related
I'm applying LSTM on time series forecasting with 20 lags. Suppose that we have two cases. The first one just using five lags and the second one (like my case) is using 20 lags. Is it correct that for the second case we need more units compared to the former one? If yes, how can we support this idea? I have 2000 samples for training the model, so this is the main limitation for increasing number of units here.
It is very difficult to give an exact answer as the relationship between timesteps and number of hidden units is not an exact science. For example, following factors can affect the number of units required.
Short term memory problem vs long-term memory problem
If your problem can be solved with relatively less memory (i.e. requires to remember only a few time steps) you wouldn't get much benefit from adding more neurons while increasing the number of steps.
The amount of data
If you don't have enough data for the model to learn from (which I feel like you will run into with 2000 data points - but I could be wrong), then increasing the number of timesteps won't help you much.
The type of model you use
Depending on the type of model you use (e.g. LSTM / GRU ) you might get different results (this is not always true but can happen for certain problems)
I'm sure there are other factors out there, but these are few that came to my mind.
Proving more units give better results while having more time steps (if true)
That should be relatively easy as you can try few different options,
5 lags with 10 / 20 / 50 hidden units
20 lags with 10 / 20 / 50 hidden units
And if you get better performance (e.g. lower MSE) with 20 lags problem than 5 lags problem (when you use 50 units), then you have gotten your point across. And you can reinforce your claims by showing results with different types of models (e.g. LSTMs vs GRUs).
I'm using the object detection api and tuning the parameters for a SSD task. My question refers to the box coder at https://github.com/tensorflow/models/blob/master/research/object_detection/box_coders/faster_rcnn_box_coder.py.
Why setting these scales factors to [10,10,5,5]? The original paper does not explain it. I suspect that it has to do either assigning a different weight to the 4 components of location error (tx, ty, tw, th) or with some numerical stability issue, but I would like to have a confirmation. Thanks
I find the answer here https://leimao.github.io/blog/Bounding-Box-Encoding-Decoding/, where the variables are used as some sort of Representation Encoding With Variance. The question was also the subject of this issue https://github.com/rykov8/ssd_keras/issues/53
The network predicts changes for each anchor box. That is, for each anchor block, it predicts an offset for x, y position and width, height.
a short description of these parameters can be found, for example to link:
https://medium.com/#smallfishbigsea/understand-ssd-and-implement-your-own-caa3232cd6ad
https://lambdalabs.com/blog/how-to-implement-ssd-object-detection-in-tensorflow/
When the cross section of the flow tube decreases, the flow speed increases, and therefore the pressure decreases.
can someone explain to me why this is true, i would think that as the cross section decreases the pressure would also increase .
This is related to "Continuity Equation" of fluid mechanisam.(Assuming fluid as incompressible)
if we have two cross-sections of areas A1 and A2 having velocities V1 and V2 respectively .Then according to continuity equation
A1*V1=A2*V2 or we can write
V2=(A1*V1)Γ·A2
V2 Is inversly proportional to the A2.
so velocity increases as the area decreases.
further we have a theorem in fluid mechanics called "Bernouli's theorem".
which states that the sum of all energies at any cross-section is constant.
So if the velocity(i.e kinetic energy) increases at any section there will be decrease in pressure(i.e pressure energy)
Think of it this way, what is pressure in the first place.!
Well pressure is the force acting perpendicular to a unit area write ?
So the fluid whatsoever particles are exerting force on that unit area, that's fine..
image five 10 people standing in an elevator standing next to each other, these guys are too much to fit inside the width of the elevator, thus they would push themselves towards the wall of the elevator making huge amount of force on the adjacent walls write ? what was that again ? aha!! huge force per area which are in this examples the walls of the elevator. hence they are too much pressure, okay.. now imagine that these people instead of standing 10 next to each others they formed themselves as groups of twos, so 5 rows of twos instead one of ten, i bet that they will feel more comfortable right? they won't push themselves that much to the wall and hence the wall will have small force on it and then small pressure, that was an example for proving that physics isn't just some numbers that define what is going to happen, Bernoulli's equation predicted that the pressure will decrease based on logic. science works :D
Suppose that we have several squares of the same size. We want to draw n rectangles (red and yellow rectangles here) to contain these squares.
The goal is to have the least wasted space possible.
In the example below, n = 2 and the solution on the right is preferred because it results in only one wasted space.
Are there any known algorithms already in place to solve these kind of problems?
UPDATE:
The arrangement of the squares is arbitrary and they are always above the X axis!
UPDATE2:
To make the question easier, let's assume that the so called container rectangles are on top of each other! (Red and yellow rectangles here)
A little more complicated case:
let's assume two rectangles are used for this one too. As it can be seen, the 3rd solution results in the least wasted space.
This question is almost identical to a hiring puzzle that ITA Software posed, called "Strawberry Fields" (scroll down for Strawberry Fields; change the greenhouse cost from 10 to 0). I can confirm that integer programming, specifically branch and price where the high-level decisions are whether to put two squares in the same rectangle, works very, very well for this problem. Here's my custom solver, written in C. You'll need to change the greenhouse cost in strawberry_fields.h from 10 to 0.
This type of rectangle cover is hard (NP-hard actually, you can use it to solve the Rectangle Cover Problem), but you can solve this with integer linear programming, as follows:
minimize sum[i] take[i] * area[i]
st
sum[i] take[i] == n
for every filled cell x,y:
sum[rectangle i covers x,y] take[i] == 1
take[i] in { 0, 1 }
Where the lists of rectangles contains only "reasonable" rectangles that you might need. ie only rectangles that cannot be made smaller without uncovering some filled cell, and you can skip certain "interior rectangles" that you can tell can never be part of a solution because they would leave a shape that's harder to cover. Generating those rectangles is a fun exercise in its own right, but generating too many isn't a big problem, just slower. In the solution, any take[i] that is 1 corresponds to a rectangle that you take.
You can throw this into any available solver, such as GLPK (free) or Gurobi (commercial and academic licenses available).
This should generally be faster than brute force, because the linear relaxation (same model as above, but the last constraint converted to 0 <= take[i] <= 1) can be used to guide the search, and various plane cutting tricks can be applied.
More advanced tricks can be found in this paper, such as tricks that use the fractional solution from the linear relaxation.
I am using scipy.optimize.fmin_l_bfgs_b to solve a gaussian mixture problem. The means of mixture distributions are modeled by regressions whose weights have to be optimized using EM algorithm.
sigma_sp_new, func_val, info_dict = fmin_l_bfgs_b(func_to_minimize, self.sigma_vector[si][pj],
args=(self.w_vectors[si][pj], Y, X, E_step_results[si][pj]),
approx_grad=True, bounds=[(1e-8, 0.5)], factr=1e02, pgtol=1e-05, epsilon=1e-08)
But sometimes I got a warning 'ABNORMAL_TERMINATION_IN_LNSRCH' in the information dictionary:
func_to_minimize value = 1.14462324063e-07
information dictionary: {'task': b'ABNORMAL_TERMINATION_IN_LNSRCH', 'funcalls': 147, 'grad': array([ 1.77635684e-05, 2.87769808e-05, 3.51718654e-05,
6.75015599e-06, -4.97379915e-06, -1.06581410e-06]), 'nit': 0, 'warnflag': 2}
RUNNING THE L-BFGS-B CODE
* * *
Machine precision = 2.220D-16
N = 6 M = 10
This problem is unconstrained.
At X0 0 variables are exactly at the bounds
At iterate 0 f= 1.14462D-07 |proj g|= 3.51719D-05
* * *
Tit = total number of iterations
Tnf = total number of function evaluations
Tnint = total number of segments explored during Cauchy searches
Skip = number of BFGS updates skipped
Nact = number of active bounds at final generalized Cauchy point
Projg = norm of the final projected gradient
F = final function value
* * *
N Tit Tnf Tnint Skip Nact Projg F
6 1 21 1 0 0 3.517D-05 1.145D-07
F = 1.144619474757747E-007
ABNORMAL_TERMINATION_IN_LNSRCH
Line search cannot locate an adequate point after 20 function
and gradient evaluations. Previous x, f and g restored.
Possible causes: 1 error in function or gradient evaluation;
2 rounding error dominate computation.
Cauchy time 0.000E+00 seconds.
Subspace minimization time 0.000E+00 seconds.
Line search time 0.000E+00 seconds.
Total User time 0.000E+00 seconds.
I do not get this warning every time, but sometimes. (Most get 'CONVERGENCE: NORM_OF_PROJECTED_GRADIENT_<=_PGTOL' or 'CONVERGENCE: REL_REDUCTION_OF_F_<=_FACTR*EPSMCH').
I know that it means the minimum can be be reached in this iteration. I googled this problem. Someone said it occurs often because the objective and gradient functions do not match. But here I do not provide gradient function because I am using 'approx_grad'.
What are the possible reasons that I should investigate? What does it mean by "rounding error dominate computation"?
======
I also find that the log-likelihood does not monotonically increase:
########## Convergence !!! ##########
log_likelihood_history: [-28659.725891322563, 220.49993177669558, 291.3513633060345, 267.47745327823907, 265.31567762171181, 265.07311121000367, 265.04217683341682]
It usually start decrease at the second or the third iteration, even through 'ABNORMAL_TERMINATION_IN_LNSRCH' does not occurs. I do not know whether it this problem is related to the previous one.
Scipy calls the original L-BFGS-B implementation. Which is some fortran77 (old but beautiful and superfast code) and our problem is that the descent direction is actually going up. The problem starts on line 2533 (link to the code at the bottom)
gd = ddot(n,g,1,d,1)
if (ifun .eq. 0) then
gdold=gd
if (gd .ge. zero) then
c the directional derivative >=0.
c Line search is impossible.
if (iprint .ge. 0) then
write(0,*)' ascent direction in projection gd = ', gd
endif
info = -4
return
endif
endif
In other words, you are telling it to go down the hill by going up the hill. The code tries something called line search a total of 20 times in the descent direction that you provide and realizes that you are NOT telling it to go downhill, but uphill. All 20 times.
The guy who wrote it (Jorge Nocedal, who by the way is a very smart guy) put 20 because pretty much that's enough. Machine epsilon is 10E-16, I think 20 is actually a little too much. So, my money for most people having this problem is that your gradient does not match your function.
Now, it could also be that "2. rounding errors dominate computation". By this, he means that your function is a very flat surface in which increases are of the order of machine epsilon (in which case you could perhaps rescale the function),
Now, I was thiking that maybe there should be a third option, when your function is too weird. Oscillations? I could see something like $\sin({\frac{1}{x}})$ causing this kind of problem. But I'm not a smart guy, so don't assume that there's a third case.
So I think the OP's solution should be that your function is too flat. Or look at the fortran code.
https://github.com/scipy/scipy/blob/master/scipy/optimize/lbfgsb/lbfgsb.f
Here's line search for those who want to see it. https://en.wikipedia.org/wiki/Line_search
Note. This is 7 months too late. I put it here for future's sake.
As pointed out in the answer by Wilmer E. Henao, the problem is probably in the gradient. Since you are using approx_grad=True, the gradient is calculated numerically. In this case, reducing the value of epsilon, which is the step size used for numerically calculating the gradient, can help.
I also got the error "ABNORMAL_TERMINATION_IN_LNSRCH" using the L-BFGS-B optimizer.
While my gradient function pointed in the right direction, I rescaled the actual gradient of the function by its L2-norm. Removing that or adding another appropriate type of rescaling worked. Before, I guess that the gradient was so large that it went out of bounds immediately.
The problem from OP was unbounded if I read correctly, so this will certainly not help in this problem setting. However, googling the error "ABNORMAL_TERMINATION_IN_LNSRCH" yields this page as one of the first results, so it might help others...
I had a similar problem recently. I sometimes encounter the ABNORMAL_TERMINATION_IN_LNSRCH message after using fmin_l_bfgs_b function of scipy. I try to give additional explanations of the reason why I get this. I am looking for complementary details or corrections if I am wrong.
In my case, I provide the gradient function, so approx_grad=False. My cost function and the gradient are consistent. I double-checked it and the optimization actually works most of the time. When I get ABNORMAL_TERMINATION_IN_LNSRCH, the solution is not optimal, not even close (even this is a subjective point of view). I can overcome this issue by modifying the maxls argument. Increasing maxls helps to solve this issue to finally get the optimal solution. However, I noted that sometimes a smaller maxls, than the one that produces ABNORMAL_TERMINATION_IN_LNSRCH, results in a converging solution. A dataframe summarizes the results. I was surprised to observe this. I expected that reducing maxls would not improve the result. For this reason, I tried to read the paper describing the line search algorithm but I had trouble to understand it.
The line "search algorithm generates a sequence of
nested intervals {Ik} and a sequence of iterates Ξ±k β Ik β© [Ξ±min ; Ξ±max] according to the [...] procedure". If I understand well, I would say that the maxls argument specifies the length of this sequence. At the end of the maxls iterations (or less if the algorithm terminates in fewer iterations), the line search stops. A final trial point is generated within the final interval Imaxls. I would say the the formula does not guarantee to get an Ξ±maxls that respects the two update conditions, the minimum decrease and the curvature, especially when the interval is still wide. My guess is that in my case, after 11 iterations the generated interval I11 is such that a trial point Ξ±11 respects both conditions. But, even though I12 is smaller and still containing acceptable points, Ξ±12 is not. Finally after 24 iterations, the interval is very small and the generated Ξ±k respects the update conditions.
Is my understanding / explanation accurate?
If so, I would then be surprised that when maxls=12, since the generated Ξ±11 is acceptable but not Ξ±12, why Ξ±11 is not chosen in this case instead of Ξ±12?
Pragmatically, I would recommend to try a few higher maxls when getting ABNORMAL_TERMINATION_IN_LNSRCH.