Wikipedia:Reference desk/Archives/Mathematics/2010 August 31
Mathematics desk | ||
---|---|---|
< August 30 | << Jul | August | Sep >> | September 1 > |
Welcome to the Wikipedia Mathematics Reference Desk Archives |
---|
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
August 31
[edit]conditional probabilities
[edit]Given
and
and
is it possible to find ?115.178.29.142 (talk) 01:20, 31 August 2010 (UTC)
- No. Here is one extreme case consistent with the information given above:
- The sample space consists of five points: v, w, x, y, z, with respective probabilities 1/20, 1/20, 8/20, 1/20, 9/20, and the events are
- A = {w, z}
- B = {w, x, y}
- C = {y, z}
- Then P(A) = 1/20 + 9/20 = 0.5,
- P(A | B) = (1/20)/(1/20 + 8/20 + 1/20) = 0.1
- P(A | C) = (9/20)/(9/20 + 1/20) = 0.9
- and P(A | B & C) = 0.
- The sample space consists of five points: v, w, x, y, z, with respective probabilities 1/20, 1/20, 8/20, 1/20, 9/20, and the events are
- Here is the opposite extreme case, also consistent with the information given above:
- The sample space consists of five points: v, w, x, y, z, with respective probabilities 1/20, 1/20, 9/20, 8/20, 1/20, and the events are
- A = {v, w, y}
- B = {w, x}
- C = {w, y, z}
- Then P(A) = 1/20 + 1/20 + 8/20 = 0.5
- P(A | B) = (1/20)/(1/20 + 9/20) = 0.1
- P(A | C) = (1/20 + 8/20)/(1/20 + 8/20 + 1/20) = 0.9
- and P(A | B & C) = 1.
- The sample space consists of five points: v, w, x, y, z, with respective probabilities 1/20, 1/20, 9/20, 8/20, 1/20, and the events are
- Michael Hardy (talk) 02:29, 31 August 2010 (UTC)
- I can't really add anything to Michael Hardy's excellent example, but I'll just say that, intuitively, your information tells you about the relationship between A & B, and also between A & C, but doesn't tell you the connection between B & C. (In terms of Venn diagrams think of overlap.) Dbfirs 19:29, 31 August 2010 (UTC)
Which experiment is the best to perform?
[edit]You have a hypothesis that you wish to test. Based on your current knowledge, you evaluate the probability that the hypothesis is true as 50%. You can choose to perform one of three experiments. You have already previously evaluated the expected probability that the hypothesis is true after performing the experiment. For experiment 1, this is 30%. For experiment 2, 60%, and experiment 3, 90%. Which experiment is expected to best perform in getting the most accurate reading for the truth/falsity of the hypothesis?--Alphador (talk) 07:13, 31 August 2010 (UTC)
- I'm not sure this question makes sense. Shouldn't the a priori expected probability that the hypothesis is true after the experiment also be 50%? An experiment will have multiple outcomes, and we could evaluate the probability that the hypothesis is true given each of the outcomes, and also evaluate the probabilities of each outcome based on our current knowledge. But if the weighted average of these probabilities is other than 50%, wouldn't that give us a different probability for the hypothesis based on our current knowledge? —Preceding unsigned comment added by 203.97.79.114 (talk) 09:45, 31 August 2010 (UTC)
- This doesn't make sense to me either. It is contradictory to say that according to your current knowledge the probability is 50%, yet you also know in advance that performing an experiment will change this to some other value. 86.173.36.196 (talk) 14:10, 31 August 2010 (UTC)
- Perhaps our article on Hypothesis testing might clarify your thinking. You might also be interested in Power of a test and also Type I error and Type II error. Dbfirs 19:14, 31 August 2010 (UTC)
- I thought the idea was to figure out the information gain from each experiment, and pick the highest one. 67.122.209.135 (talk) 20:59, 1 September 2010 (UTC)
- That would be possible if we were given sufficient data. The data given by the OP is not only insufficient, but also inconsistent. -- Meni Rosenfeld (talk) 09:21, 2 September 2010 (UTC)
The law of total probability says:
- The prior expected value of the posterior probability is equal to the prior probability.
Michael Hardy (talk) 23:04, 1 September 2010 (UTC)
May I ask a silly question; regarding the Calandar and how we work-out rates to pay ?
[edit]I am finding myself trying to explain to well educated people on this subject, but are not Maths. / Accountancy perhaps. I have been trying to explain that a rate of rent per calandar month is a payment of twelve per year and so is to 12 * 4 = 48 weeks. A rate per year is to 52 weeks. Yet a Company is trying to fit one into soft-ware that does not fit. Am I wrong? MacOfJesus (talk) 11:13, 31 August 2010 (UTC)
- If you pay monthly then there are twelve payments a year, but this doesn't mean there are 48 weeks in a year. If you pay yearly then there is one payment a year, regardless of whether there are exactly 52 weeks in a year (which there aren't). 86.173.36.196 (talk) 14:06, 31 August 2010 (UTC).
Thank you. I was being over-simplistic, for now I have (The un-enviable task) of telling Bosses this! MacOfJesus (talk) 17:00, 31 August 2010 (UTC)
- When I ran a weekly and monthly payroll, the yearly pay was divided by 52.142857 to obtain the weekly pay. This meant that those on weekly pay were actually paid for an extra day every leap year, and thus earned slightly more than those who elected for monthly pay. Dbfirs 19:04, 31 August 2010 (UTC)
- But was that 12 monthly payments per year or 13? Or did it just roll-over from one year to the next? And, would it not be better to divide it by 365, or 365.25, the yearly sum, and then multiply it my the appropriate number of days for the weekly packet? MacOfJesus (talk) 21:18, 31 August 2010 (UTC)
- Monthly payments (in the UK at least) are paid on or before a fixed date of the month, so there are 12 in a year. Weekly payments are always exactly seven days (usually paid on Friday), so there is no advantage in dividing by 365.25 because it gives exactly the same result. Dbfirs 07:51, 1 September 2010 (UTC)
- But people don't work 7 days a week, usually. Mostly 5 or 6. And, bosses are miserable with wage-paying! MacOfJesus (talk) 08:09, 1 September 2010 (UTC)
- One solution to the whole problem is just to agree on an hourly rate, then record the number of hours worked in any convenient period. The problem with this method is that it usually cheats employees out of paid bank holidays, paid holiday, and paid sick-leave (though the first two of these these can be incorporated in the hourly rate by an enlightened employer, and sick-leave can be paid at an "average rate"). Dbfirs 08:45, 3 September 2010 (UTC)
- Each calendar month has on average 365.25/12 = 30.4375 days in it, not the 28 days you implied above. And on average there are 365.25/7 = 52.17857143 weeks in the year. Each year consists of 52 weeks plus one day plus any leap day. 92.15.3.64 (talk) 16:47, 2 September 2010 (UTC)
- You simply need to explain that things don't fit quite right, therefore we have to approximate.
You have estimates and exact values. there are 365.2422 days in a year, we arbitrary divide it into 12 months, giving approximately 30 days to a month, the exact value being 365.2422/12. So a given month gives approximately 4.2 weeks or 365.2422/7. A real world example of approximations is tax rates. if you tax rate is 10% what is the tax on USD 1.01? and where does the 10% of USD$0.01 go? To answer your question, you are wrong. Your calculation for weeks should be 4.2 ( You need to increase your accuracy to give you balances to the nearest cent, which means at least a few more digits of accuracy. There is approximately 52.17745 weeks in a year, or approximately 4.348 weeks in a month, and exactly 7 days in a week. Let me rephraise your question if you please: " I have been trying to explain that a rate of rent per calendar month ( is the rate that would give you 12 payments over 365.2422 days or one sidereal year ) is a payment of twelve per year ( exactly by definition ) and so is to 12 ( exactly ) * 4 ( 4.333... ) = 48 ( 52 exactly ) weeks. A rate per year is to 52 ( approximatly ) weeks. ( 52.17745 exactly )
Blame it on the earth, not revolving exactly 360 days. It will someday as it slows, but until then we have to approximate. ( and btw, that extra 5.2422 days is not silly to a USD$120,000 month rent ) —Preceding unsigned comment added by 69.232.209.57 (talk) 20:21, 2 September 2010 (UTC)
Random permutation
[edit]Initially:
a(1) = 1
a(2) = 2
...
a(n) = n
Then:
for i = 1 to n
r = random number between 1 and n (inclusive)
swap the values of a(i) and a(r)
next
Question: will this produce a uniformly random permutation of 1,2..n in a() (i.e. all permutations equally likely)? If not, is there a simple tweak that will fix it so it does? —Preceding unsigned comment added by 86.173.36.196 (talk) 14:01, 31 August 2010 (UTC)
- No, it won't: you have possibilities for your set of random numbers and for your output orders. so it can't be uniform. See Knuth shuffle. --Tardis (talk) 14:20, 31 August 2010 (UTC)
- Knuth shuffle is unbiased. If the random number generator is also unbiased, why won't the result be uniform? -- kainaw™ 14:32, 31 August 2010 (UTC)
- Because the OP's algorithm does not do Knuth shuffle. Knuth shuffle is the "simple tweak that will fix it".—Emil J. 14:39, 31 August 2010 (UTC)
- Wow. After so many years of grading programming homework, I feel ashamed that I overlooked that. -- kainaw™ 02:10, 1 September 2010 (UTC)
- Because the OP's algorithm does not do Knuth shuffle. Knuth shuffle is the "simple tweak that will fix it".—Emil J. 14:39, 31 August 2010 (UTC)
- Knuth shuffle is unbiased. If the random number generator is also unbiased, why won't the result be uniform? -- kainaw™ 14:32, 31 August 2010 (UTC)
- The OP's biased algorithm is discussed in the second paragraph of Fisher–Yates shuffle#Implementation errors. -- ToET 15:04, 31 August 2010 (UTC)
Elementary number theory problem
[edit]Let and k be any positive integers. Prove that if and only if . The hint attached to the problem in the book says, let . I started with the hint, and saw that (n-1) divides always. Now I cant think of anything else to do. I feel the hint was supposed to send me in another direction. Can someone help please. Thanks -Shahab (talk) 15:35, 31 August 2010 (UTC)
- You can continue in the same direction: compute an explicit expression for m = (nk − 1)/(n − 1) (hint: think about these as polynomials in variable n), and determine when n − 1 | m (hint: if p(x) is an integer polynomial and n and c are integers, then p(n) ≡ p(c) mod (n − c)).—Emil J. 15:51, 31 August 2010 (UTC)
- (edit conflict) Use the binomial theorem to expand . Subtract 1 and divide by and you are left with a sum of multiples of powers of and a constant term. All the multiples of powers of are obviously divisible by . What is the value of the constant term ? Gandalf61 (talk) 15:55, 31 August 2010 (UTC)
- @Emil: I have used your hint as follows: and so taking , , and c=1 in your hint we have . Now suppose . Clearly then and so as required. Supposing gives us and combined with this yields . I hope this is all correct.
- @Gandalf61: The constant term is k, but I dont understand your approach. Could you be more explicit. Thanks-Shahab (talk) 16:21, 31 August 2010 (UTC)
- Gandalf's suggestion is actually much simpler than mine. Just expand nk − 1 = (1 + (n − 1))k − 1 in terms of powers of n − 1 using the binomial theorem. The ith powers for i ≥ 2 are always divisible by (n − 1)2, and the 0th power cancels out, which only leaves us with the term involving the 1st power, which you computed to be k(n − 1). Then it should be obvious when is this divisible by (n − 1)2.—Emil J. 16:37, 31 August 2010 (UTC)
- Oh yes. Why do many problems appear extremely simple once the solution is presented! Thanks for all the help-Shahab (talk) 16:54, 31 August 2010 (UTC)
- Gandalf's suggestion is actually much simpler than mine. Just expand nk − 1 = (1 + (n − 1))k − 1 in terms of powers of n − 1 using the binomial theorem. The ith powers for i ≥ 2 are always divisible by (n − 1)2, and the 0th power cancels out, which only leaves us with the term involving the 1st power, which you computed to be k(n − 1). Then it should be obvious when is this divisible by (n − 1)2.—Emil J. 16:37, 31 August 2010 (UTC)