January 2009 - mathfun@mailman.xmission.com

[math-fun] Passing thought for a textbook
by David Wolfe 10 Jan '09

10 Jan '09

Just a passing thought: A mathematics textbook with a single exercise at the front of the book which reads, Every proof in this book has one (deliberately introduced) technical error, and may also have inadvertent errors. Correct all proofs. David

2 3

[math-fun] Does anyone know (anyone who knows) Malay, Slovak, Slovenian, Welsh ?
by N. J. A. Sloane 09 Jan '09

09 Jan '09

The OEIS has the top page translated into 36 languages, but those 4 are the main ones that are missing. All that I need is a translation of ten simple sentences. To see the sentences, go to the main OEIS lookup page, and click on the red link to "Languages". For languages with a non-Western alphabet, it is best to type the sentences into Microsoft Word and send me the doc file. Word can then produce the Unicode characters that I need. Neil

2 1

Re: [math-fun] muffin problem
by Michael Reid 08 Jan '09

08 Jan '09

> Erich Friedman noticed a nice reciprocity between m and n: if we let > S(m,n) denote the size of the smallest piece when m muffins are split > among n noshers, then nS(m,n) = mS(n,m). > > So, for instance, Rich's observation that S(4,7) is at least 5/21 > implies reciprocally that S(7,4) is at least 5/12. interesting! this suggests to consider instead the function T(m, n) which is the maximum c for which there is a partition of 1 with each part >= c , and that is a simultaneous refinement of 1/m + 1/m + ... + 1/m and also of 1/n + 1/n + ... + 1/n . (as per erich's proof, T(m, n) = S(m, n) / m .) moreover, this has the obvious generalization to T(n_1, n_2, ... , n_s) , the maximum c for which there is a partition of 1 with each part >= c , and that is a simultaneous refinement of 1/n_i + 1/n_i + ... + 1/n_i for each i . by the way, i (believe i) can prove that rich's splitting is indeed optimal, and that it is the only way to achieve optimality. before i type in all the details of my proof (and discover the gaps!) can you let me know if you're interested? mike

2 1

[math-fun] muffin problem
by James Propp 08 Jan '09

08 Jan '09

Alan Frank (a friend of mine and Andy Latto's) asks, what's the best way to divide m identical muffins among n people, so that each person gets the same amount of muffin (receiving either one piece of size m/n or several pieces whose sizes add up to m/n), where "best" means "so as to maximize the size of the smallest piece". For example, if 4 muffins are to be divided among 7 people, and if each piece has size of the form i/7 for some i, then it is easy to show that one of the pieces must have size 1/7 (it isn't possible for everyone to get either 4/7 or 2/7+2/7). But we can improve on this by dividing two of the muffins 5:5:4 and dividing the other two 3:3:8 and then giving everyone either 5/14+3/14, 4/14+4/14, or 8/14 of a muffin; this is better since the smallest piece has size 3/14 > 1/7. Jim Propp

3 2

Re: [math-fun] muffin problem
by James Propp 07 Jan '09

07 Jan '09

Erich Friedman noticed a nice reciprocity between m and n: if we let S(m,n) denote the size of the smallest piece when m muffins are split among n noshers, then nS(m,n) = mS(n,m). So, for instance, Rich's observation that S(4,7) is at least 5/21 implies reciprocally that S(7,4) is at least 5/12. It has a really nice proof (maybe the problem should be submitted as a Quickie to the Monthly): Hint: Instead of muffins, use sticks. If you break m equal-length sticks into pieces that can be reassembled to form n equal-length sticks, then it's easy to take those n sticks and re-reassemble them to form m equal-length sticks: just use the breaks you've already made! Jim

1 0

[math-fun] morning silliness
by rcs＠xmission.com 06 Jan '09

06 Jan '09

(From this morning's Wall Street Journal) Mathematicians Land Top Spot in New Ranking of Best and Worst Occupations in the U.S. Mathematicians' annual income was pegged at $94,160. http://online.wsj.com/article/SB123119236117055127.html Rich

1 0

Re: [math-fun] Zune doesn't zzzing any more
by Steve Witham 05 Jan '09

05 Jan '09

>From: "Tom Rokicki" <rokicki(a)gmail.com> > >And lest you think that's not a problem, consider that in 9999 we'll all be >emulating hardware from 9950 emulating hardware from 9930 emulating >hardware from 9900 . . . all the way down probably to emulating that C64. > >And it will *still* run faster than the C64. Compute pressure is actually caused by gajillions of computers booting up, emulating each other, and shutting down all around us. If they were all to hit the same bug at the same time, we couldn't breath. --Steve Waiter, there are 6*10^23 molecules on my chicken. SI, Senor, that is our recipe.

1 0

Re: [math-fun] Zune doesn't zzzing any more
by Dan Asimov 04 Jan '09

04 Jan '09

As I see it, anytime days > 367 (if leap year) or days > 366 (if not), the program should SCREAM. --Dan << [Reminds me of the "phase of the moon" bug ... http://www.ccil.org/jargon/jargon_31.html] comp.risks had more info on the Zune calendar freeze bug: > http://forums.zune.net/412486/ShowPost.aspx The issue is an infinite loop: > while (days > 365) { > if (IsLeapYear(year)) { > if (days > 366) { > days -= 366; > year += 1; > } > } else { > days -= 365; > year += 1; > } > } > Under normal circumstances, this works just fine. The function keeps > subtracting either 365 or 366 until it gets down to less than a year's > worth of days, which it then turns into the month and day of month. Thing > is, in the case of the last day of a leap year, it keeps going until it > hits 366. Thanks to the if (days > 366), it stops subtracting anything if > the loop happens to be on a leap year. But 366 is too large to break out > of the main loop, meaning that the Zune keeps looping forever and doesn't > do anything else. >> _____________________________________________________________________ "It don't mean a thing if it ain't got that certain je ne sais quoi." --Peter Schickele

3 2

[math-fun] Zune doesn't zzzing any more
by Henry Baker 04 Jan '09

04 Jan '09

[Reminds me of the "phase of the moon" bug ... http://www.ccil.org/jargon/jargon_31.html] comp.risks had more info on the Zune calendar freeze bug: > http://forums.zune.net/412486/ShowPost.aspx The issue is an infinite loop: > while (days > 365) { > if (IsLeapYear(year)) { > if (days > 366) { > days -= 366; > year += 1; > } > } else { > days -= 365; > year += 1; > } > } > Under normal circumstances, this works just fine. The function keeps > subtracting either 365 or 366 until it gets down to less than a year's > worth of days, which it then turns into the month and day of month. Thing > is, in the case of the last day of a leap year, it keeps going until it > hits 366. Thanks to the if (days > 366), it stops subtracting anything if > the loop happens to be on a leap year. But 366 is too large to break out > of the main loop, meaning that the Zune keeps looping forever and doesn't > do anything else.

1 0

Re: [math-fun] Correlation puzzle NEW!
by Dan Asimov 02 Jan '09

02 Jan '09

I wrote: << PUZZLE ------ Given real-valued random variables X,Y,Z in a joint distribution, suppose that the correlation coefficient* between any two of them is the same number C. QUESTION: What is the minimum value, over all such joint distributions, that C can take? (We assume all means and variances are finite.) >> Gene and Veit found the lowest possible value, -1/2. (How Gene came up with his streamlined reasoning, I may never know.) Here is a related puzzle, hot off the press: PUZZLE: Let (x,y,z) be chosen at random from the uniform distribution on [-1,1]^3. If you guess that (x,y,z) actually forms a triple of correlation coefficients from 3 jointly distributed real random variables, are you more likely to be right or to be wrong? --Dan _____________________________________________________________________ "It don't mean a thing if it ain't got that certain je ne sais quoi." --Peter Schickele

1 0