Jump to content

Wikipedia:Reference desk/Archives/Mathematics/2014 May 11

From Wikipedia, the free encyclopedia
Mathematics desk
< May 10 << Apr | May | Jun >> Current desk >
Welcome to the Wikipedia Mathematics Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


May 11

[edit]

Red vs. Black differences

[edit]

If I deal out a shuffled deck of cards, the chance that the absolute value of the number of red cards - the number of black cards will always be one or less is 2^26 * 26! * 26! / 52! (it must be 26 consecutive pairs of one red and one black in either order). The change that the absolute value of the difference is always twenty five or less is 1 - (2*26!*26!/52!) since the only ones that would fail are all 26 red then all 26 black or the other way around.

First is the a formula that can be used with the numbers in between? And regardless, what is the number for the difference that comes closest to being an even bet? Naraht (talk) 14:43, 11 May 2014 (UTC)[reply]

I think your formula for the probability of the absolute value of the difference being less than or equal to 1 is incorrect.
If I understand you correctly, you have a shuffled standard deck of 52 cards, and you are dealing 26 cards to a person B. There are 52!/(26!)2 possibilities for which cards B gets, ignoring the order in which he gets them. Only some of these possibilities will obey your condition, which in the case of the absolute value of the difference of the numbers of red cards and black cards being 1 or less is really simply that B gets 13 black cards and 13 red cards. Now the probability is the ratio of the number of possibilities that obey your condition and the total number of possibilities.
The number of possibilities of getting 13 black cards (out of the 26 black cards) and 13 red cards (out of the 26 red cards) is (written in binomial coefficients and then in factorials):
Thus, the probability is
That turns out to be a relatively large probability, about 0.22.
More, generally, the probabilitiy for B receiving exactly k red cards is
And for the probability that the absolute value of the difference in numbers of cards that you are looking for is less than or equal to some number n I don't know a simpler formula than
The factor of 2 in all the terms of the enumerator (except the initial term) comes from the fact that if you have 12 red cards and 14 black cards you could also have 14 red cards and 12 black cards etc.
The probability for the absolute value of the difference being less than or equal to 2 is already about 0.59.
Icek (talk) 21:25, 11 May 2014 (UTC)[reply]
No, you don't understand me correctly. By deal out, I'm talking from shuffled deck to upturned on table, counting the number of red cards and the number of black cards at any given time. If my number is 4, then the deal is successful if at all times the difference between the number of red cards dealt and the number of black cards dealt is 4 or less. So if the cards start out RRBRRRBRRR... and number is 4, that is a failure since we've reached 7 red and 2 black so the difference is 5.Naraht (talk) 21:56, 11 May 2014 (UTC)[reply]
Sorry for the misunderstanding.
I don't have a formula, only a simple algorithm.
Imagine the whole game as a non-descending walk on a square lattice with 26 times 26 squares (i.e. 27 times 27 points). The horizontal distance from the left border is the number of black cards that have been dealt, and the vertical distance from the lower border is the number of red cards that have been dealt.
Now your problem translates into staying within a certain strip around the diagonal that runs from the lower left to the upper right corner.
Now consider certain n-tuples of points, where each tuple contains all the points on a certain line that is perpendicular to the aforementioned diagonal and are within the allowed strip around the diagonal. In the case of n = 2, we have the initial 2-tuple comprising the points (0,1) and (1,0); the next 2-tuple will contain the points (1,2) and (2,1), and so on. In the case of n = 3, it would start with the 3-tuple (0,2), (1,1), (2,0). There will be 28-n such tuples.
I will use the integer i starting at 0 to index the points within a tuple, and the integer j starting at 0 to index the tuples themselves, so that a certain tuple will be referred to as tj and a certain point within a tuple will be referred to as tj,i.
Number of possibilities to get from the origin (point (0,0) at the lower left) to point t0,i:
The number of possibilities to get from a point t27-n,i to the upper right corner will obviously be the same, and all that is left to calculate is the number of possibilities between one tuple and the next (there is no allowed path from a point of one tuple to another point of the same tuple) and multiply everything and sum at the end.
From a point tj,i, assuming it's not in the last tuple, there are always 2 paths to the point tj+1,i, and, assuming there is one path to tj+1,i-1, and, assuming , there is one path to tj+1,i+1.
Let pj,i denote the number of possibilities for reaching the point tj,i. Then we have the algorithm:
for and :
Total number of possibilities =
Icek (talk) 16:35, 12 May 2014 (UTC)[reply]
Your answers do not appear to have the width of the strip as a variable, so that the number of ways to reach the point 26,26 is the same regardless. The width of the strip affects these calculations since the number of ways to create the point 20,20 (for example) would be different if the allowed width the strip is 3 or 9.Naraht (talk) 17:34, 12 May 2014 (UTC)[reply]
I forgot to point out that in my calculations n is the maximal absolute value of the difference of the numbers of red and black cards. Icek (talk) 18:03, 12 May 2014 (UTC)[reply]

Help with Amortization Calculation

[edit]

Initial loan amount is $99,900. We want the payment to be $1,000/mo. Loan will balloon after 24 months with a payoff of $84,900 at that time. ($15,000 of the total monthly payments are principal, and $9,000 of the total monthly payments are interest.) Can you help me calculate the amortization schedule? I can't get the years/interest rate to jive. I could get as close as a 10 year loan at 3.75%, as this puts the payment at $999.61/mo, but the payoff would only be $82,795.10 and we need the payoff to be $84,900. I really hope this makes sense. Thanks so much!! — Preceding unsigned comment added by 71.29.13.114 (talk) 22:36, 11 May 2014 (UTC)[reply]

Assuming payments are credited at the beginning of each month and interest accrues once a month, I get a monthly interest rate of 0.408343%, which gives an equivalent annual rate (compounded) of 5.0117%. This tallies with the back-of-an-envelope estimate which says you are repaying roughly 10% of the loan over 2 years so you expect the annual interest rate to be around 5%. Gandalf61 (talk) 12:15, 12 May 2014 (UTC)[reply]

The interest factor x=1+r, where r is the monthly interest rate, satisfies the equation

I get r=0.403950258%, slightly less than Gandalf's solution. Bo Jacoby (talk) 19:42, 12 May 2014 (UTC).[reply]

Yes, that assumes payments are credited at the end of each month. To get my value, which assumes payments are credited at the start of each month, the summation runs from 1 to 24 instead of from 0 to 23. Gandalf61 (talk) 09:17, 13 May 2014 (UTC)[reply]

I see! Thank you. Bo Jacoby (talk) 11:54, 13 May 2014 (UTC).[reply]

In order to solve the equation approximately with less use of brute computer force the powers of x=1+r are expanded by the binomial theorem:

Swapping the two summations:

Performing the summation over i:

Extracting the low-order terms:

This equation in r is still of degree 24, but the high order terms are small and an approximate equation is

which has the solution

which is a useful approximation to the correct monthly rate of interest. It is obtained without solving an equation of high degree. Bo Jacoby (talk) 22:15, 14 May 2014 (UTC). (I changed the equations to have integer coefficients). Bo Jacoby (talk) 15:10, 15 May 2014 (UTC).[reply]