April 2006 - mathfun@mailman.xmission.com

RE: [math-fun] A problem for the shower
by Cordwell, William R 27 Apr '06

27 Apr '06

I think that solid rocket motors try to achieve this, where the fuel has something of a star-shaped hole in the middle, and, as it burns, the amount of fuel exposed (surface area) stays roughly constant (so as to give a constant thrust). The hole gradually becomes "smoother", which keeps the surface area constant as the hole gets larger. Going backwards probably doesn't work, I would guess. Bill C. -----Original Message----- From: math-fun-bounces+cordwell=sandia.gov(a)mailman.xmission.com [mailto:math-fun-bounces+cordwell=sandia.gov@mailman.xmission.com]On Behalf Of David Wolfe Sent: Wednesday, April 26, 2006 10:27 AM To: math-fun Subject: [math-fun] A problem for the shower A question struck me in the shower this morning: Suppose you would like a piece of soap which dissolves at a uniform rate. I.e., as it gets smaller, the soap bar's surface area remains constant until it vanishes. I have convinced myself that one should be able to construct such a bar of soap with arbitrarily small holes. As the soap gets smaller, the holes are exposed to increase the surface area. Need it have holes? _______________________________________________ math-fun mailing list math-fun(a)mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun

1 0

[math-fun] Judge Embeds a Puzzle in 'Da Vinci Code' Ruling
by Henry Baker 27 Apr '06

27 Apr '06

FYI -- http://www.nytimes.com/2006/04/27/books/27code.html The New York Times April 27, 2006 Judge Embeds a Puzzle in 'Da Vinci Code' Ruling By SARAH LYALL LONDON, April 26 Â Justice Peter Smith's 71-page ruling in the recent "Da Vinci Code" copyright case here is notable for many things: the judge's occasional forays into literary criticism, his snippy remarks about witnesses on both sides, and his fluent knowledge not only of copyright law but also of more esoteric topics like the history of the Knights Templar. But there is more to it than that. Embedded in the first 13Â½ pages of the ruling is Justice Smith's very own secret code, one that when partly solved reveals its name: the Smithy Code. "The key to solving the conundrum posed by this judgment is in reading HBHG and DVC," the judge writes in the 52nd paragraph of the ruling, alluding to his code and referring to the two works at issue in the case Â"The Holy Blood and the Holy Grail" and "The Da Vinci Code" Â by their initials. (In the United States, the book is called "Holy Blood, Holy Grail.") On April 7 Justice Smith ruled that Random House, publisher of the megaselling "Da Vinci Code," did not violate the copyright of "The Holy Blood and the Holy Grail," a nonfiction work published in 1982 that spins an elaborate theory about how Jesus married Mary Magdalene and how their descendants still live in southern France. Two of the book's authors contended that Dan Brown, who wrote "The Da Vinci Code," lifted the central "architecture" of their book and had thus violated their copyright. (The third author of "Holy Blood, Holy Grail," Henry Lincoln, did not participate.) The decision was a resounding slap in the face to the two plaintiffs, Michael Baigent and Richard Leigh. But it was also an opportunity for Justice Smith to indulge in a flight of judicial and cryptological fancy. The first clue that a puzzle exists lies in the typeface of the ruling. Most of the document is printed in regular roman letters, the way one would expect. But some letters in the first 13Â½ pages appear in boldface italics, jarringly, in the midst of all the normal words. Thus, in the first paragraph of the decision, which refers to Mr. Leigh and Mr. Baigent, the "s" in the word "claimants" is italicized and boldfaced. If you pluck all the italicized letters out of the text, you find that the first 10 spell "Smithy Code," an apparent play on "Da Vinci Code." But the next series of letters, some 30 or so, are a jumble, and this is the mystery that needs to be solved to break the code. In a brief telephone interview on Wednesday, Justice Smith declined to provide a solution for a puzzled reporter. Nor would he explain how he had put the code in his ruling, or how long it took him to figure out how to do it. "I can't discuss the judgment until after I retire," he said. But in a series of brief and ultimately frustrating e-mail messages during the last couple of days, the judge provided a series of intriguing clues. First he said that the different ways codes are broken in "Holy Blood, Holy Grail" and "The Da Vinci Code" should be considered. The idea for the italicized letters, he suggested, came from "Holy Blood, Holy Grail." He then suggested moving on to "The Da Vinci Code" and applying one of the code-breaking methods used by its protagonists to solve the mystery of the jumbled letters. "Think mathematics," he wrote at one point. He drew attention to his own entry in Who's Who Â in which he lists an interest in the history of Jackie Fisher, an admiral who modernized the British Navy, a possible reason that his e-mail address contains the word "pescator," implying fisherman Â and said that the date 2006 was significant. He even mentioned a page number in "The Da Vinci Code" by way of trying to help. But he declined to go further, saying that "anything else gives it on a plate." It has been nearly three weeks since he handed down the ruling. Probably disappointingly for Justice Smith, nobody seemed to notice anything unusual about it when it was first released. But he alluded to the possibility that there was something more soon afterward as a throwaway line in an e-mail exchange with a reporter for The New York Times, saying, "Did you find the coded message in the judgment?" On vacation in Florida, the judge then declined via e-mail to elaborate much further, other than to refer to anomalies in the typeface. "Start with 's' and keep looking up to Page 18 approximately when the fonts stop," he wrote. Meanwhile, back in London, Daniel Tench, a partner at the law firm Olswang, was reading the ruling and noticed something odd about the type. "At first I thought it was a mistake," he said on Wednesday. "It's not usual practice for a High Court judge to issue a ruling in which he has hidden an encrypted message." Not knowing if there was anything there, though, Mr. Tench mentioned it to a reporter who compiles a column about legal affairs for The Times of London. After that paper printed a small item quoting him discussing the typeface, Mr. Tench was nonplussed to receive an e-mail message from Justice Smith confirming that yes, there was indeed a code, but that Mr. Tench had missed the first letter "s." "It is always best to start at paragraph 1!" the judge wrote. Speaking to the Bloomberg news service late on Wednesday, Justice Smith once again declined to provide any answers. Explaining why he made up his own code, he said it was "a bit of fun."

1 0

[math-fun] Decimation-like sequences
by Eric Angelini 27 Apr '06

27 Apr '06

Please have a look there, http://www.cetteadressecomportecinquantesignes.com/Decimation.htm Best, É.

1 0

[math-fun] 6x6 pandiag. multiplic. squares ARE NOT impossible!
by Christian Boyer 27 Apr '06

27 Apr '06

Ooops... Rereading the Sayles's article, he found a 6x6 pandiagonal multiplicative square in 1913... With the same set of integers than my first example (and of course the same product 1.02 E+14). My second example has a product 8.58 E+13. Here is a third example with a new better product 2.99 E+12: 5 720 160 45 80 1440 4800 12 150 192 300 6 9 400 288 25 144 800 320 180 10 2880 20 90 75 48 2400 3 1200 96 576 100 18 1600 36 50 It is now the best known square using the smallest product. However its MaxNb 4800 is bigger than the MaxNb 4410 of the second example. Open problems: -Is 2,985,984,000,000 the smallest possible product? -Is 4410 the smallest possible MaxNb? Christian.

1 0

RE: [math-fun] arctan: update sieving and a fun relation
by Schroeppel, Richard 27 Apr '06

27 Apr '06

You can use very rough approximate logarithms. In my factor sieving code, I used base cbrt2, and my logs all fit in a 9-bit field. Computing these logs is pretty fast: find the highest bit of N, left normalize, compare to the normalized 2^(1/6) and 2^(3/6). The final quotient in your factorization of X^2+1 is either close to 1, or very far away; so you can tolerate a lot of rounding noise from subtracting approximate logs. On today's processors, there's likely no benefit to using bytes, but you still only need a couple of bits of mantissa precision for your logs. You can compute log(prime) with a table lookup on the high order few bits. But as you say, "fast enough". Rich -----Original Message----- From: math-fun-bounces+rschroe=sandia.gov(a)mailman.xmission.com [mailto:math-fun-bounces+rschroe=sandia.gov@mailman.xmission.com] On Behalf Of Joerg Arndt Sent: Tuesday, April 25, 2006 11:22 AM To: math-fun Subject: Re: [math-fun] arctan: update sieving and a fun relation I have been extremely pedantic about machine specific issues like (level one) cache size, alignment, and (CPU) internal parallelism. Plus I carefully inspected the machine code of every version of my code and also benchmarked each. I had up to 3 priority queues: 1) very frequent events 2) events that occur reasonably often 3) rare events I was very surprised that even dropping the last brought a speedup, even if it held only _very_ rare events. I have only vague ideas about why this is: as the code is so fast already one sees code and data dependencies that are not seen in less optimized code. For example, now I have two tables of events, rare and not-so-rare plus a unrolled prefill phase (length ten, taking care of log(2), log(5), and log(10) ). Initially I had the sequence prefill, not-so-rare, rare Changing that to prefill, rare, not-so-rare Gives a small but consistent speedup. The maximum gain possible with smarter event handling for the rare events can be tested by simply leaving them out: You don't get lower than 11 cycles (!) Btw. the "compute log only after sum greater than that of last found X" trick reduces the numer of actual log computations to exactly the number of smooth X found. Note what a devastating impact log computations (which take 150 cycles or so) would have for the performance. One might get down to 10 cycles using SIMD instructions. However, my experiences with (hand-written) SSE2 code has been quite discouraging. Plus SSE set is probably the worst anti-orthogonal attempt of an instruction set until today (i.e., painful to code, even more so producing fast code). So I do the lazy thing by stating: "it's fast enough!" Anyway, thanks for the multi-bin idea! For those still reading, I am using % gcc --version gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) which produces scalar but breathtakingly well optimized (and often beautiful!) machine code. Producing hand-coded assembler that beats the gcc machine code is, if possible at all, extremely hard. Machine is a AMD64 @2.2GHz, 939 socket, dual channel DDR 200, memtransfer is 2GB/sec when far beyond cache. Important CPU characteristics are Name: AMD Athlon(tm) 64 Processor 3400+ Family: 15, Model: 15, Stepping: 0 Level 1 cache (data): 64 kB, 2-way associative. 64 bytes per line, lines per tag: 1. Level 1 cache (instr): 64 kB, 2-way associative. 64 bytes per line, lines per tag: 1. Level 2 cache: 512 kB, 16-way associative 64 bytes per line, lines per tag: 1. fpu: x87 FPU sse: Streaming SIMD Extensions sse2: Streaming SIMD Extensions-2 cmov: CMOV instruction (plus FPU FCMOVCC and FCOMI) If you consider a x86 system, then go for AMD64. The document http://swox.com/doc/x86-timing.pdf tells you why, in every little detail. End of advertisement :o) * Schroeppel, Richard <rschroe(a)sandia.gov> [Apr 25. 2006 18:17]: > A potential problem with dropping the priority queues is the amount > of random memory access. If your problem won't fit in the memory > cache, things slow down a lot. There's a way of organizing priority > queues that drops most of the (heavy) reorganization overhead. The > key idea is to use a larger base like 256, instead of 2. Bins come in > a few sizes: the stuff to be processed in the immediate future (about > 256 cells), the less-than immediate future (256 cells, each holding > unsorted values in a width-256 range), and the far future (256 cells, > each holding a width-65536 range). You spend the bulk of your time > doing whatever processing is required for individual values. > When a low-level 256-range is completed, you open up the next higher > level cell and spread out its contents into the low-level > 256 array. There's never any sorting, and only one or two levels of > rebinning into smaller bins. You can tinker with the bin-size ratios > at each level to optimize your problem; there's nothing sacred about > 256. The advantage of this scheme is that it's compatible with cache > memory, and will even work tolerably if there are disk files involved. > > One interesting gimmick with divisor lists is that the insertion of a > next-number-with-this-divisor item, (item: N+D, divisor D) into slot > N+D can always be at the top of the list. When the time comes to > process N+D, the list of divisors will be in sorted > (increasing) order already. > > Rich > > [...] _______________________________________________ math-fun mailing list math-fun(a)mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun

2 1

RE: [math-fun] arctan: update sieving and a fun relation
by Pacher Christoph 27 Apr '06

27 Apr '06

>> For those still reading, I am using % gcc --version gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) which produces scalar but breathtakingly well optimized (and often beautiful!) machine code. Producing hand-coded assembler that beats the gcc machine code is, if possible at all, extremely hard. Machine is a AMD64 @2.2GHz, 939 socket, dual channel DDR 200, memtransfer is 2GB/sec when far beyond cache. Important CPU characteristics are Name: AMD Athlon(tm) 64 Processor 3400+ Family: 15, Model: 15, Stepping: 0 Level 1 cache (data): 64 kB, 2-way associative. 64 bytes per line, lines per tag: 1. Level 1 cache (instr): 64 kB, 2-way associative. 64 bytes per line, lines per tag: 1. Level 2 cache: 512 kB, 16-way associative 64 bytes per line, lines per tag: 1. fpu: x87 FPU sse: Streaming SIMD Extensions sse2: Streaming SIMD Extensions-2 cmov: CMOV instruction (plus FPU FCMOVCC and FCOMI) If you consider a x86 system, then go for AMD64. The document http://swox.com/doc/x86-timing.pdf tells you why, in every little detail. >> have you tried to use the PathScale compiler www.pathscale.com ? Often it gives an improvement on the order of -30% in execution time compared to gcc. Also the Intel compiler (icc) should be faster than gcc. If you want, I could compile for you on both compilers on an AMD64 (Opteron) machine and send you the binaries for benchmarking... Christoph

2 1

[math-fun] Hero[n]'s formula
by Gareth McCaughan 27 Apr '06

27 Apr '06

As all munsters know, area^2 = s(s-a)(s-b)(s-c) = xyz(x+y+z). Is there a really good proof of this? The best one I've been able to cook up[1] says: let t,u,v = tan A/2 etc.; then xt=r (the inradius) etc., so t:u:v = 1/x:1/y:1/z, and (tangent-sum formula, angle-sum of triangle) uv+vt+tu=1, so t = 1/x / sqrt(1/yz+1/zx+1/xy), so r^2 = 1/(1/yz+1/zx+1/xy) = xyz/(x+y+z) and as rs=area we're done. But this feels a bit too complicated. Is there perhaps a neat proof in 4 or 6 dimensions that looks at the cartesian product of the triangle (or some tetrahedron with the triangle as base) with itself? [1] Presumably it's been known for centuries. -- g

5 7

[math-fun] mathpuzzle.com is missing
by Dave Dyer 27 Apr '06

27 Apr '06

Mathpuzzle.com has gone missing.

2 1

Re: Correction Re: [math-fun] Hero[n]'s formula
by dasimov＠earthlink.net 26 Apr '06

26 Apr '06

I wrote: << . . . but should have worded the last sentence as: << Again the p-otenuse has one right corner at the origin of the positive orthant, and the rest of them must be "p-acute" -- defined by requiring that each angle between two edges emanating from this corner is acute. >> >> But more to the, uh, point: each dihederal angle between two hyperplanes bounding the p-otenuse is acute. --Dan

1 0

Correction Re: [math-fun] Hero[n]'s formula
by dasimov＠earthlink.net 26 Apr '06

26 Apr '06

I wrote: << More generally the shape of an arbitrary right p-simplex (p-tetrahedron) is made by an affine hyperplane in R^p that intersects each positive coordinate axis. Again, the p-otenuse has one right corner at the origin of the posiive orthant, and the rest of them must be "p-acute" -- defined by requiring that each dihedral angle at the corner is acute. >> but should have worded the last sentence as: << Again the p-otenuse has one right corner at the origin of the positive orthant, and the rest of them must be "p-acute" -- defined by requiring that each angle between two edges emanating from this corner is acute. >> --Dan

1 0