April 2018 - mathfun@mailman.xmission.com

[math-fun] Infinite product of the type of François Viet for atan (x)
by françois mendzina essomba2 10 Apr '18

10 Apr '18

Looking at the first infinite product of pi found by François Viet, I deduced an infinite product of atan(x) (2/sqrt(2/(17*sqrt(5))+2))*(2/sqrt(sqrt(2/(17*sqrt(5))+2)+2))*(2/sqrt(sqrt(sqrt(2/(17*sqrt(5))+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(2/(17*sqrt(5))+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(2/(17*sqrt(5))+2)+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(sqrt(2/(17*sqrt(5))+2)+2)+2)+2)+2)+2)) * ... =(17*sqrt(5)*atan(38))/38; (2/sqrt(sqrt(sqrt(sqrt(sqrt(sqrt(sqrt(2)/5+2)+2)+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(sqrt(2)/5+2)+2)+2)+2)+2))* (2/sqrt(sqrt(sqrt(sqrt(sqrt(2)/5+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(2)/5+2)+2)+2))*(2/sqrt(sqrt(sqrt(2)/5+2)+2))*(2/sqrt(sqrt(2)/5+2)) * ... =(5*sqrt(2)*atan(7))/7 ; And in a general way (2/sqrt(2/(sqrt(x^2+1))+2))*(2/sqrt(sqrt(2/(sqrt(x^2+1))+2)+2))*(2/sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2)+2)+2)+2))* ... = sqrt(1/x^2+1)*atan(x) ; An approximation of order 6 will be (2/sqrt(2/(sqrt(x^2+1))+2))*(2/sqrt(sqrt(2/(sqrt(x^2+1))+2)+2))*(2/sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2)+2)+2))*(2/sqrt(sqrt(sqrt(sqrt(sqrt(sqrt(2/(sqrt(x^2+1))+2)+2)+2)+2)+2)+2)) = sqrt(1/x^2+1)*atan(x);

1 0

Re: [math-fun] Who's going to G4G13?
by Richard Hess 10 Apr '18

10 Apr '18

I’m on my way now. Dick Sent from my iPhone > On Apr 10, 2018, at 9:41 AM, Scott Kim <scott(a)scottkim.com> wrote: > > I'll be going. -- Scott > >> On Tue, Apr 10, 2018 at 8:57 AM, Allan Wechsler <acwacw(a)gmail.com> wrote: >> >> No Jenny or Allan this year, I'm afraid. We will miss seeing you and >> Hilarie :( >> >>> On Tue, Apr 10, 2018 at 11:55 AM, Tomas Rokicki <rokicki(a)gmail.com> wrote: >>> >>> Susie and I will be there! >>> >>>> On Tue, Apr 10, 2018 at 8:02 AM, <rcs(a)xmission.com> wrote: >>>> >>>> Hilarie & I will be at Gathering for Gardner. >>>> Who else is going? >>>> >>>> Rich >>>> >>>> >>>> >>>> _______________________________________________ >>>> math-fun mailing list >>>> math-fun(a)mailman.xmission.com >>>> https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun >>>> >>> >>> >>> >>> -- >>> -- http://cube20.org/ -- http://golly.sf.net/ -- >>> _______________________________________________ >>> math-fun mailing list >>> math-fun(a)mailman.xmission.com >>> https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun >>> >> _______________________________________________ >> math-fun mailing list >> math-fun(a)mailman.xmission.com >> https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun >> > _______________________________________________ > math-fun mailing list > math-fun(a)mailman.xmission.com > https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun

4 3

[math-fun] Who's going to G4G13?
by rcs＠xmission.com 10 Apr '18

10 Apr '18

Hilarie & I will be at Gathering for Gardner. Who else is going? Rich

4 3

[math-fun] Draft of April 2018 blog post
by James Propp 10 Apr '18

10 Apr '18

I’m writing an essay called “Who Knows Two?” (to be made public a week from today) and would appreciate comments: https://mathenchant.wordpress.com/?p=2247&shareadraft=5acb8145805a2 Is my description of Frege’s work on number correct? What about my description of intuitionism? Is it okay that the article meanders so much, or should I restructure the opening to make it clearer where I’m going? Is there stuff I should cut or shorten (e.g., the Endnote about misreading Latin declension tables)? Or is there stuff I should add? (The piece is already on the long side, but if you know some really juicy things about primitive roots, I’ll consider adding them, or at least adding a reference.), As always, I hope you’ll sign your comments so that I can ask follow-up questions if need be. Thanks, Jim Propp

2 1

[math-fun] The asymptotic muffin problem
by James Propp 10 Apr '18

10 Apr '18

It occurred to me after Bill Gasarch's recent MIT Combinatorics Seminar talk that there's a problem related to the muffin problem that has just a single real parameter, which plays the same role as m/n but can be irrational; call it p (for portion). We have infinitely many muffins and infinitely many noshers. Each muffin gets divided into pieces, and each piece is given to one of the noshers, in such a fashion that each piece gets eaten and each nosher gets p muffins. Let F(p) be the infimum of the sizes of the pieces. What can we say about F(p)? For instance, is it periodic with period 1? Or could F(p+1) be smaller than F(p) for some p? Note that when p is rational, F(p) = inf f(m,n) over all pairs m,n with m/n = p. (Or is it? This seemed obvious when I wrote it, but now I’m not so sure. There are two inequalities in this claim, and right now I’m not seeing how to prove either of them.) Can anyone compute F(p) for some quadratic irrational p, such as (-1+sqrt(5))/2? (That's probably asking for too much; I can’t even determine F(2/n) for all odd n.) Jim Propp

1 0

Re: [math-fun] Miss those IBM/DEC blinking lights?
by Bill Gosper 10 Apr '18

10 Apr '18

The PDP-6 display had a 1024×1024 point raster, randomly addressable at 30 μs a pop. To gain insight into integer lattice reduction, Rich had me display all 2^20 points, sorted by fractional part of x π + y e, with a ~30 second period. The appearance was a nonrectangular creeping grid. But depending on ambient lighting, visual acuity, and caffeine consumption, different viewers saw different grids. You could find fast grids by guessing a velocity vector and sweeping your finger thusly across the screen. If there was such a grid, your brain could lock onto it. To hide a picture or message, slightly perturb the temporal order of those points you want to stand out. Only viewers skilled at seeing rapid grids will notice. --rwg It should also be possible to Morse-code messages by rapidly blinking LED auto taillights to leave dotted and dashed afterstreaks, if you know how to look. On 2018-04-09 16:49, Bernie Cosell wrote: > On 9 Apr 2018 at 15:46, Mike Beeler wrote: > >> ... Nowadays, >> even if the PC were easily available, instruction rate is way too fast >> for a CRT to keep up with, but perhaps a pseudo-random sampling would >> accomplish the same effect. However, it wasn’t helpful enough to be a >> great tool, IMHO. > > Got me wondering. I worked with BBN's PDP-1d, which was a very > tricked-out PDP-1 (it had two drums, 9-channel mag tape drives, > the prototype of the PDP-6 memory bank machinery). All of that > stuff had lights on almost every register. The 'lights bank' was the > width of the PDP-1 console and went to the ceiling, packed with > lights all the way (Mike might have see that system.. I don't think > any of you had). I got very good at understanding what was going > on in the timesharing system just by a glance at the lights. Mike > got me wondering what that lights display would be like with > modern components. The displays on the two drums would be > unreadable -- all the lights on, but at varying brightnesses. Same > with the main CPU registers and everything else. But then, beyond > that, I got to wondering if a suitable savant could still do what I did > but by understanding the brightness patterns as they flowed back > and forth > > /B\ > > Bernie Cosell > bernie(a)fantasyfarm.com > -- Too many people; too few sheep --

1 0

Re: [math-fun] Miss those IBM/DEC blinking lights?
by Henry Baker 10 Apr '18

10 Apr '18

My first computer job (in high school) was working at the University of Cincinnati Medical School computer center, where we had an IBM 7040/1401 *tape* system (no disk!). The bulk of our computing work involved very long statistical regressions (some took all weekend) and radiation treatment planning (basically the inverse problem to a CAT scan). (Google University of Cincinnati Medical School and its dubious ethical history -- especially with DoD and radiation studies.) We also trained *blind programmers* (Google Dr. Theodore Sterling), who worked with the SW we developed for printing Braille on an IBM 1403 printer modified with a soft cloth behind the paper so that the paper would bulge after being hit with a ".". One of the blind programmers got so good at "reading" these 14" wide Braille printouts that he took his shirt off and simply pressed the printout against the skin on his chest! After our IBM "customer engineer" told us that computers interfered with radio reception -- and demonstrated this with a portable transistor radio -- the blind programmers started using this radio "side-channel" to let them know how their program was progressing. For them, it was the equivalent of our "blinking lights". (We didn't attempt to compute large powers modulo large primes, but these computers would have been so slow that one could have written down the bits of the exponents by hand from the radio signals.) At 09:25 PM 4/8/2018, Tomas Rokicki wrote: >I remember both the HP-21MX and PDP-11 lights as "glowing with >varying brightness" but you could still figure out what your code was >doing by just *how* bright individual bits were . . . I'm going to have >to make a USB blinky-lights console for my Mac . . . maybe I'll put >some toggle switches on it too.

5 5

[math-fun] Keep your Lisp's Zipf'd
by Henry Baker 09 Apr '18

09 Apr '18

[Try pronouncing that phrase fast!] Just for the heck of it, I instrumented one of the "Gabriel" benchmarks for Lisp -- the Boyer benchmark -- which operates solely on Lisp CONS cells, and never damages these cells using RPLACA/RPLACD. I wanted to see what the cache performance of an ideal LRU *data* cache would be for this benchmark, so I computed the statistics on the "move to front" behavior of the various CONS cells involved in this computation. The most important statistic is the so-called "stack distance" -- the number of positions between the current position on the LRU list and the front of the list. We can accumulate for each stack distance the number of times a "move to front" traverses that particular distance. If one runs a typical computation long enough, the sequence of these stack distances tends to fall off as n^(-beta), typically 1.3 < beta < 1.7 (note that beta=1 for Zipf). A higher beta means greater "locality": the cache is more effective; a lower beta means that the cache is less effective. Interestingly, the beta I measured for Boyer is ~1.2666, which places it below the normal range for programs studied by computer architects, and may explain some of the poor cache performance of Lisp on architectures not optimized for Lisp. BTW, my instrumented Boyer never does GC, because any garbage cells quickly get pushed out of the early cache levels and hence don't get in the way of the ongoing computation. (See also Jon L White's paper "GC Considered Harmful".) Now this assumption could be wrong: the whole point of "nurseries" and "generational GC's" is that the % of garbage is so high, that large numbers of tiny GC's can reclaim CONS cells *while they're still in the cache*, and thus avoid cluttering up the cache with dead cells. On the other hand, a "write-allocate" cache can also perform a CONS entirely within the cache, so the only downside of garbage is the cost of eventually writing the garbage back to backing store; since the write-back mechanism can be deeply pipelined, the effective cost of writing back garbage is overlapped and hence quite small. I'll also be comparing the behavior of this "classical" Boyer with the behavior of a "hash consed" Lisp memory, where it is always the case that (EQ (CONS x y) (CONS x y)), i.e., a "hash consed" Lisp "uniquizes" cons cells based upon their CAR&CDR contents. I want to see if hash consing produces a better beta. I'll also be measuring an *instruction cache* for a McCarthy-style Lisp interpreter to see what a beta for an instruction cache might look like.

1 2

[math-fun] Lucky accident
by Bill Gosper 09 Apr '18

09 Apr '18

Looking to illustrate spacefilling by using continuously varying colors, with no tricky phases and sampling frequencies, I found gosper.org/blackdrag.png which looks nice all black yet shows the course of the spacefill, using only actual dyadic rationals from the Dragon recursion. The trick is to replace every triad of consecutive points by a triangle with those vertices. It might be tweakable into one of those inside|outside https://pictures.abebooks.com/isbn/9780262630221-us-300.jpg Minsky-Papert perceptron confusers. Not that gosper.org/mediandrag2.png isn't confusing enough. --rwg

5 9

Re: [math-fun] Miss those IBM/DEC blinking lights?
by Bill Gosper 09 Apr '18

09 Apr '18

I've mentioned here before the amazing console lights of the Univac 1206 (https://en.wikipedia.org/wiki/AN/USQ-20) "The machine was the size and shape of an old-fashioned double-door refrigerator <https://en.wikipedia.org/wiki/Refrigerator>, about six feet tall (roughly 1.80 meters)." Unmentioned: Those doors were inches thick and closed like a bank vault with interlocking brass teeth. The photo shows it up on a palette to admit the prodigious quantity of air that it sucked and exhausted out the stack on top. It could Bernoulli-levitate a football. The console lights were neon-like, and were actually push buttons that complemented the bit they indicated, which seemed to include every bit in the processor. E.g., you could compute the first few factorials with a zero-instruction program by putting the processor into the state: Single step, Repeat Advance, Multiply Immediate 1. I remember the amazement of the undergads that the PDP-1 lights didn't blink. The machine was so fast that they just glowed with varying brightness. Except for one. The early models had a light labeled Halt Store, which no one had ever seen lit, until someone left a paper tape on the console labeled "Turn on Halt Store". (The IBM blinking reflected slow IO devices.) The PDP-1, like the Univac 1218, was 18bit 1's complement, as favored by Seymour Cray. The objection to 1's complement was that x+(-x) gave 11111... = -0. The PDP-1 simply "gronked" -0 via a special kudge (which missed a single example). Cray ingeniously avoided the -0 problem via hardware subtract with end-around borrow instead of hardware add with end-around carry. The story at Univac was that Cray refused to cooperate with the 1206 design team or even accept the specifications of management. When the deadline came, the design team had nothing, and management was forced to build Cray's solo design. --rwg Date: 2018-04-08 09:17 From: Victor Miller <victorsmiller(a)gmail.com> To: math-fun <math-fun(a)mailman.xmission.com> Reply-To: math-fun <math-fun(a)mailman.xmission.com> In the summer of 1966 I was working at the Rome (NY) Air Development Center, on a Univac 1218 computer (a militarized verson of the 418). It was an 18 bit ones-complement machine. On the console were two banks of lights each in a 6 x 3 format. The machine had a primitive time sharing system, and the lights on the console normally displayed a pattern which was I L (for idle loop). I found out where the pattern was stored and one day I changed it to read FU. The Univac engineer came in, saw it, and said "things aren't that bad, arey they?". I just stared at him, and he said, well, I guess they are.

2 1