Wikipedia:Reference desk/Archives/Mathematics/2019 December 7
Mathematics desk | ||
---|---|---|
< December 6 | << Nov | December | Jan >> | Current desk > |
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. |
December 7
[edit]Circle Game
[edit]A child wants to play a circle game under the following rule. All children sit in a circle. The child gets up and counts one child and taps them on the head, then two kids and taps that one and so on (including the ghost person sitting where he was). He wants a number of kids to play so that the following happens. He goes around the circle more than once, but doesn't tap any child more than once. Can he play this game? I'm not sure.
The number of kids must be a large divisor of a Triangular number (Tn), but I haven't been able to find an example. For example, if there are 18 children (36=T8), child 3 gets tapped twice, once at count 3(T2), once at 21(T6). If there are 40 children (120=T15), child 15 gets tapped twice, once at 15(T5), and again at 55(T10).
More formally. Do x,y & z exist so that x*y=Tz and for all 1<=v,w< z Tv!=Tw mod x. (x =#of kids, y=#of times around, z=number of taps that get him home) And if they do exist what is the smallest x for y=2 and smallest x for y = 3.Naraht (talk) 03:10, 7 December 2019 (UTC)
- Ok, now I've got that Joni Mitchell song playing in my head. So, to clarify, you want to find n (>1) and t with n|T(t) so that T(1), T(2), ... , T(t) are distinct mod n, where T(k) = k(k+1)/2. Wlog you can assume that t is the smallest number >0 so that n|T(t), since once you've landed back at the start going around additional times only makes it more unlikely that there will be no repeats. --RDBury (talk) 13:22, 7 December 2019 (UTC)
- PS. You're also requiring T(t) > n, otherwise n = T(k) would work for any k. --RDBury (talk) 13:33, 7 December 2019 (UTC)
- Sounds like a reasonable restatement.Naraht (talk) 14:30, 7 December 2019 (UTC)
- I'm guessing that if the statement is true it will be at best rather messy to prove. It does seem possible to narrow down the search based on the factorization of n though. Specifically, you can eliminate those n whose largest prime factor is > √(2n). First notice that
- So if n=kp then Also, exploiting the assumption that p is a prime dividing T(t), we have t≥p-1. Eliminating t and k then gives a bound on p in terms of n. There doesn't seem to be an easy way to determine t from n; it's given by OEIS: A011772 though. --RDBury (talk) 16:52, 7 December 2019 (UTC)
- I'm guessing that if the statement is true it will be at best rather messy to prove. It does seem possible to narrow down the search based on the factorization of n though. Specifically, you can eliminate those n whose largest prime factor is > √(2n). First notice that
- Sounds like a reasonable restatement.Naraht (talk) 14:30, 7 December 2019 (UTC)
- Update, there is still much more that can be said about this problem and I'm becoming convinced that there is no n where someone does not get tagged twice. More formally:
- If k>1, n≥1, T(t) = kn, then there are a, b, with 1≤a<b<t so that T(a)≡T(b) (mod n).
- Focusing on k instead of n as I did earlier seems to be much more productive. In particular the original post asked about the cases k=2 and k=3 and I believe I have a proof the statement for these two values and a number of others. The outline of the proof for a fixed k is more or less the same in each case, but a unified proof that applies to all k seems to be more difficult. 1) Classify t so that k|T(t) according to congruence classes mod k or 2k depending on whether k is even or odd. For k=2 we get t=4p or t=4p+3. In general the number of congruence classes is 2d where d is the number of distinct prime powers of k (OEIS: A034444). 2) Then n is determined by T(t) = kn. For k = 2 this is n=p(4p+1) when t=4p and n=(p+1)(4p+3) when t=4p. The general form seems to be (ap+b)(cp+d) where ac = k or 2k, ad-bc=1. 3) Find a congruence of the form T(p) = T(xp+y) mod n for some fixed x and y. When n=p(4p+1), T(p) = T(3p) mod n. (In fact T(3p) - T(p) = n. When n=(p+1)(4p+3), T(p) = T(3p+2) mod n. I think it's possible to prove that:
- For a, b, c, d positive with ad-bc =1, there is x≠1 and y so that p(p+1) ≡ (xp+y)(xp+y+1) mod (ap+b)(cp+d) for all p.
- 4) If the x given in step 3 is greater than 1 and less than k then we are done except for a finite number of cases. This is where the proof fails to generalize for all k since it seems you need to check that x is in the required range, verify the result for small p where xp+y>t, and account for the 2 in the denominators when applicable, all by hand for the 2d cases for a given k; this relatively trivial if k is known and small but seems intimidating when k is arbitrary. --RDBury (talk) 17:44, 9 December 2019 (UTC)
- Update, there is still much more that can be said about this problem and I'm becoming convinced that there is no n where someone does not get tagged twice. More formally:
- I must be misunderstanding this. Surely if there are n children, and each receives at most 1 tap, then to complete the game there must be n taps. But since there are n spaces at which a tap can be received (because of the requirement that the empty space is included in the tapping process) the n-th tap must occur at the same place as the (n-1)th tap, so that child must receive 2 taps. So the game cannot be completed as wished. What have I misunderstood? RomanSpa (talk) 15:36, 12 December 2019 (UTC)
- Should I be assuming that if a tap occurs at the empty space it is not allocated to the child running round the circle? RomanSpa (talk) 15:39, 12 December 2019 (UTC)
- You're thinking you should just be able to apply the Pigeonhole principle, which is what I thought when I first read the description. But it may take much less than n taps to get back to the start and despite this there always seems to be someone who gets tapped twice before it happens. Take, for example, n=18. The following are tapped: 1, 3, 6, 10, 15 (first time around), then 3, 10, 0 (start). It only takes 8 taps to return to the start, which is when the game ends, but the 3rd and 10th children are tapped twice. The problem stipulates that you must go around more than once, otherwise any triangular number like n=15 would work. For n=15, since you must go around more than once, the children tapped are 1, 3, 6, 10 (first time around), 0 (start), 6, 13 (second time), 6 (third time), 0 (start). In this case 6 is tapped three times before the game ends. I'd venture to go a bit farther and conjecture that one of the children tapped on the first time around is tapped again before the end. --RDBury (talk) 22:10, 12 December 2019 (UTC)
- Should I be assuming that if a tap occurs at the empty space it is not allocated to the child running round the circle? RomanSpa (talk) 15:39, 12 December 2019 (UTC)
Round 251 to the nearest hundred
[edit]251 is greater than 250, so it's clear that it rounds to 300. But some Internet sites say that when a 5 appears in the appropriate position, whether you round up or down depends on whether the digit before is odd or even; this means that 251 should round to 200 because 2 is an even digit. Any reason for this rule?? Georgia guy (talk) 23:03, 7 December 2019 (UTC)
- See Rounding#Round half to even. –Deacon Vorbis (carbon • videos) 00:04, 8 December 2019 (UTC)
- However, I seem to have misread your question. No, rounding to the nearest hundred would always be to 300 for 251. –Deacon Vorbis (carbon • videos) 00:09, 8 December 2019 (UTC)
- I'm with Deacon Vorbis here. The answer is clearly 300. No convoluted logic about the oddness or evenness of the preceding digit applies. HiLo48 (talk) 00:21, 8 December 2019 (UTC)
- Yes, the "5" rule only applies in the case where the rounding is removing just one significant digit and that digit is 5. --142.112.159.101 (talk) 05:08, 8 December 2019 (UTC)
- @Georgia guy: The rule you mention applies when the digit 5 is the only digit being removed by rounding. So it would apply to the number 250, in which case the result is 300, or to 350 in which case the result would be 300, too. In the more general case "round to the nearest K" means "find the closest integer multiple of K". So to round 251 to 100 we can divide 251:100=2.51 and apply the ordinary rounding to integer. Obviously round(2.51)=3, because the fraction part exceeds a half, hence the answer is 3×100=300. --CiaPan (talk) 10:22, 8 December 2019 (UTC)
Obviously round(2.51)=3
This is what is known as begging the question. --JBL (talk) 03:12, 13 December 2019 (UTC)- Why do you think so, JBL? IMHO it's not. --CiaPan (talk) 09:30, 13 December 2019 (UTC)
P.S. Please use {{reply to}} unless you want to show others you don't care if they read your comments... --CiaPan (talk)- @CiaPan: I actually don't care if others read my grouchy RD comments :) ; but since you asked I am pinging you this time. You took the question of how to round something, transformed it to an exactly isomorphic question of how to round something, and then declared the answer "obvious". This is begging the question. (The actual answer to the OP's question is that they are misunderstanding the rule in DV's first link, and both DV and HL had already noted that rounding 251 is straightforward.) --JBL (talk) 12:21, 13 December 2019 (UTC)
- Why do you think so, JBL? IMHO it's not. --CiaPan (talk) 09:30, 13 December 2019 (UTC)
- 250, 251, 252... should all round to 300. Also 25 should round to 30 and 35 to 40 (if rounding to nearest ten). Checking whether the penultimate digit is even or odd when the number ends in 5 means you round down 55% of time and up 45% of time. You need to always round up when the most significant discarded digit is 5. 93.136.71.134 (talk) 22:23, 10 December 2019 (UTC)
Checking whether the penultimate digit is even or odd when the number ends in 5 means you round down 55% of time and up 45% of time.
No, there are 5 even digits and 5 odd digits. This is all covered at the article Rounding. --JBL (talk) 22:47, 10 December 2019 (UTC)