August 2013 - mathfun@mailman.xmission.com

[math-fun] vactrain, ballistic transport
by Warren D Smith 18 Aug '13

18 Aug '13

Considering the miserable USA cannot even create a conventional-wheeled high speed rail line (suitable straight-enough track too costly), it seems absurd to ask for a vactrain (way more costly, plus even greater straightness demands). The "ballistic" plan seems also absurd (high G forces, plus what if it misses the target a bit?). Maybe those who like these should consider the Jules Verne plan, where we tunnel straight thru the earth to Australia, evacuate tunnel, and then gravity supplies almost all necessary forces. "Simple." I believe that we're going to run out of fossil fuels whereupon fast cheap air transport may vanish forever. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)

5 4

[math-fun] Fwd: Q about a (planar-)partition bijection
by James Propp 18 Aug '13

18 Aug '13

Igor Pak writes: ---------- Forwarded message ---------- From: Igor Pak Date: Saturday, August 17, 2013 Subject: [math-fun] Q about a (planar-)partition bijection To: James Propp <jamespropp(a)gmail.com> Dear Jim, The bijection is classical, but highly non-trivial. It is a variation on the Hillman-Grassl bijection, itself a variation on RSK. The shortest answer to this question is in my partition bijections survey (see link below), section 9.1. Best, -- Igor http://tinyurl.com/kudbqem On Sat, Aug 17, 2013 at 3:34 AM, James Propp <jamespropp(a)gmail.com> wrote: > Dear Igor, > > Surely you would know of such a thing! > > Jim > > ---------- Forwarded message ---------- > From: Joerg Arndt > Date: Friday, August 16, 2013 > Subject: [math-fun] Q about a (planar-)partition bijection > To: math-fun <math-fun(a)mailman.xmission.com> > > > Hesitatingly, I'll dare ask a question of > rather specific nature: > > The generating function of planar partitions is > 1 / prod(n>=1, (1 - q^n)^n ) > Now that is also the g.f. of (the usual) partitions > with one sort of 1, two sorts of 2, three of 3, etc. > > I am the only person on this planet that cannot > figure out a (natural, constructive) bijection? > > Best, jj > > > _______________________________________________ > 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] "firewall paradox" about black holes
by Henry Baker 17 Aug '13

17 Aug '13

From _our_ perspective of the outside world, things that 'fall into' the black hole _never get there_, because time just gets slower & slower (GR time dilation) until at the horizon itself time stops. So all of the _information_ that 'fell into' the black hole still resides in our universe, except that from our perspective it is now painted on the _surface_ of the black hole. This is one way to see Bekenstein's argument that the information 'content' of a black hole is proportional to its surface area. --- BTW, I was watching a lecture at UCSB's KITP where the claim was made that particles that 'fall into' a black hole 'release' an amount of energy equal to their gravitational potential energy, which can be ~ 50% of their _rest mass_. I haven't done the calculations, but if we can attribute the 'rest mass' of a particle to its _potential energy_ as a result of being pulled out of a black hole, who needs Higgs Bosons to give us rest mass ? So we get all of our mass from the potential energy from being separated from every other mass in the universe? Mach was right, after all: http://en.wikipedia.org/wiki/Mach's_principle At 04:38 PM 8/13/2013, Warren D Smith wrote: >in NY Times today, graphic is here: > >http://www.nytimes.com/interactive/2013/08/13/science/0813-sci-blackhole.ht… > >does my (already discussed) quantum decoherence picture already resolve this paradox? >Needs thought...

8 12

[math-fun] secret key cryptosystem?
by Warren D Smith 17 Aug '13

17 Aug '13

>Mike Stay metaweta at gmail.com >Sat Aug 17 19:32:49 MDT 2013 > AES or Threefish. > Any recommended secret-key cryptosystems? > > My desiderata are simple+short algorithm and high security level. > Speed is not very important. --I don't think so. The AES implementation here: https://polarssl.org/aes-source-code is 1400 lines long. I repeat, my top priority is simple+short algorithm.

4 3

[math-fun] old piano rolls
by Warren D Smith 17 Aug '13

17 Aug '13

there's already a big community of people on the internet trying to scan old piano rolls, salvage old phonograph recordings etc, and they have machines to do it. E.g. http://www.trachtman.org/rollscans/

1 0

[math-fun] Turning piano rolls into MIDI files
by Keith F. Lynch 17 Aug '13

17 Aug '13

Some of the most interesting math problems are ones that relate to the real world. I was recently loaned an antique piano roll to scan in with my flatbed scanner and turn into a MIDI file. (You can hear it at <http://KeithLynch.net/2202.mid>. 2202 is its serial number. I have no idea what the tune is called.) The piano roll consists of a regular square lattice of holes, much like a punched card or punched paper tape. My first problem was to figure out the alignment, since it's all but impossible to feed it into the scanner perfectly straight. When I scanned my old punched paper tapes last year, I used the edges of the tape as reference, but that wasn't practical for the piano roll as the edge was too ragged due to wear. So I used the holes themselves. The holes are all circular and the same size. I identified the holes, as N coterminous black pixels with N in a certain range. (The contrast was of course cranked all the way up, so every pixel was either pure white or solid black.) I located the center of each hole, by averaging the locations of its pixels. Then I constructed lines between the centers of the holes, and looked for the modes of the slopes of these lines. As I expected, those modes were the horizontal and vertical axes. (Is this a known algorithm? Is there a better one?) A complication is that the mode of a set of floating point numbers isn't well defined. I used binning. Details on request. Another complication was dealing with near-vertical slopes. I swapped X for Y when slopes became too great. Unsurprisingly, the two axes aren't quite at right angles to each other. I'm not sure how much of this skew is intrinsic to the piano roll and how much iss an artifact of rotation combined with non-square pixels. Another complication is that many of the holes were not recognized as such, as they were too large due to two holes merging. But this wasn't a problem, since this algorithm is quite robust for moderate numbers of missing or spurious holes. (Of course I had to do something else to rediscover those missing holes later, so they would turn into sounds.) The one problem with this algorithm is it's O(N^2) in the number of holes. But that's not much of a problem since there are usually only about a hundred holes per scan page. Another problem with this piano roll was that someone had made purple marks on it, which can be mistaken for holes. Fortunately, I was using a color scanner. It was a simple matter to subtract the values of the green pixels from the sum or the red and blue before cranking up the contrast. (I'm doing all of this processing in my own C program, after reverse-engineering the TIFF format. I also had to reverse-engineer the MIDI format.) (I was using a large black book as backing, so that the holes would look black. Appropriately enough it was also an antique book. But it was not an antique scanner.) Puzzle: Suppose there had also been green marks on it? How would I also get rid of them in software? Then, since the reward for a job well done is more work, I was given several more piano rolls. Even though these were intended for the same piano, they are quite different. Instead of circular holes, there are long thin holes, like many overlapping circular holes. In other words they're hot-dog shaped. So I need to rewrite the axis- finding code. The obvious approach is to to find the long axis of each hole, as those should all be parallel and should be the horizontal axis. What's the best way to do that? One approach would be to start with any point in the hole, find the most distant point in the hole from that point, find the most distant point in the hole from *that* point, find the most distant point in the hole from *that* point, etc., until I'm finding the same two points each time. Is this guaranteed to always converge to the correct two points in any finite set of points? How many steps might it take? But wait, in some of the piano rolls the long thin holes don't have round ends, but square ones. The holes are rectangles. The long axis of such a hole is of course a diagonal, which is not what I want. Nor am I guaranteed to find as many "/" diagonals as "\" diagonals, so I don't want to rely on binning averaging them out. Any ideas on how to efficiently find the long central axis of a rectangle with arbitrary orientation? Well, not quite arbitrary. The slope should never be as much as 1/10. Also, some of these piano rolls have black marks on them. How can I distinguish holes from them? (Yes, I know the answer to this one.)

2 1

Re: [math-fun] Ballistic hyperloop
by Henry Baker 17 Aug '13

17 Aug '13

Speaking of lasses, Google Elliana Grace Hentoff-Killian, who routinely experiences G-forces of 7 doing her job, and who was interviewed on NPR a few months ago. At 09:10 PM 8/16/2013, Fred Lunnon wrote: ><< We carefully select the amount of injected fuel to simply >make up for the lasses in the system. >> > > Of course, if it's men only, there shouldn't be any ... > >WFL > >On 8/17/13, Henry Baker <hbaker1(a)pipeline.com> wrote: >> I'll check out the Commutapult. >> >> My idea came from Saddam Hussein's Project Babylon, which followed from the Canadian >> Project HARP by Gerald Bull, who got the idea from the WWII German 'V-3' (follows V-2, >> I guess.) >> >> http://en.wikipedia.org/wiki/Project_Babylon >> >> http://en.wikipedia.org/wiki/V-3_cannon >> >> At 04:25 PM 8/16/2013, Victor S. Miller wrote: >>>In case you haven't seen the Commutapult: >>>http://igniteshow.com/videos/commutapult-ep-68 >>> >>>Sent from my iPhone >>> >>>On Aug 16, 2013, at 16:08, Henry Baker <hbaker1(a)pipeline.com> wrote: >>> >>>> Elon Musk's 'hyperloop' (a.k.a. 'vactrain') has been all over the news the past several days. >>>> >>>> http://en.wikipedia.org/wiki/Vactrain >>>> >>>> http://en.wikipedia.org/wiki/Pneumatic_tube >>>> >>>> The main problem, as I see it, is the incredibly expensive infrastructure required, not just >>>> at its endpoints, but all along the path. >>>> >>>> I think it would be faster & cheaper to do what I call a 'ballistic hyperloop'. >>>> >>>> As Crocodile Dundee might have said, "now _that's_ a hyperloop!". >>>> >>>> Here's the idea: >>>> >>>> Launch a _ballistic_ projectile from L.A. towards S.F. At the SF end, there is a 'receiver' >>>> that is basically a time-reversed launcher. >>>> >>>> I hope that the following (flat Earth) calculations are correct. >>>> >>>> It is approximately 560km (348 miles) from LA to SF. >>>> >>>> If we launch our vehicle from LA to SF at a velocity of 1.97 km/s (4400mph) at a 45 degree >>>> elevation, our vehicle will arrive in SF in about 402 seconds (6:42). >>>> >>>> The vehicle will reach a height of 49.5 km (31 miles). >>>> >>>> In order to keep the acceleration to within approx 6 g's, we need about 33 seconds of >>>> acceleration, during which time we travel about 33km (about 20 miles). >>>> >>>> 20 miles of infrastructure is too much to put even on a mountain side in L.A., so >>>> we have to do better. >>>> >>>> If we put the passengers into a water-filled container, we might be able to do >>>> 12 g's, which would reduce the acceleration distance to perhaps 10 miles, which would >>>> be easily doable on Interstate 5 to the north of Los Angeles. >>>> >>>> A 'normal' landing would require slightly less acceleration in reverse due to the >>>> atmospheric losses on launching and landing. >>>> >>>> An 'abnormal' landing would require a parachute, and would happen if the onboard >>>> computers decided that it would be impossible to land safely in the 'receiver'. >>>> >>>> Here's why it is a 'loop'. >>>> >>>> At the receiving end (Mt Tam?), the projectile comes in and starts pushing air >>>> through a tunnel to the SF-to-LA launcher. This air is 20% oxygen, and it will get >>>> very hot, very quickly. We now inject some fuel -- e.g., diesel fuel, liquid natural >>>> gas, etc. -- into this air. We carefully select the amount of injected fuel to simply >>>> make up for the lasses in the system. The incoming projectile thus transfers its >>>> momentum & energy to the outgoing projectile, with enough added energy to make up for >>>> the losses, and the SF-to-LA projectile is now on its way. >>>> >>>> Yes, you get a little wet & have to take a shower when you arrive in SF, but if you >>>> are subjected to 12g's for 16.4 secs on launching and 16.4 secs on landing, you'll >>>> probably wet yourself anyway. >>>> >>>> Total time, including showers: 30-45 minutes. >>>> >>>> _No_ infrastructure required, except at the launching & receiving ends. >>>> >>>> Forget SpaceX; this will be the real E-ticket ride at Six Flags Magic Mountain >>>> (off I5 north of LA). >>>> >>>> Needless to say, the noise outside will be incredible, both on launching >>>> and landing.

1 0

[math-fun] Ballistic hyperloop
by Henry Baker 16 Aug '13

16 Aug '13

Elon Musk's 'hyperloop' (a.k.a. 'vactrain') has been all over the news the past several days. http://en.wikipedia.org/wiki/Vactrain http://en.wikipedia.org/wiki/Pneumatic_tube The main problem, as I see it, is the incredibly expensive infrastructure required, not just at its endpoints, but all along the path. I think it would be faster & cheaper to do what I call a 'ballistic hyperloop'. As Crocodile Dundee might have said, "now _that's_ a hyperloop!". Here's the idea: Launch a _ballistic_ projectile from L.A. towards S.F. At the SF end, there is a 'receiver' that is basically a time-reversed launcher. I hope that the following (flat Earth) calculations are correct. It is approximately 560km (348 miles) from LA to SF. If we launch our vehicle from LA to SF at a velocity of 1.97 km/s (4400mph) at a 45 degree elevation, our vehicle will arrive in SF in about 402 seconds (6:42). The vehicle will reach a height of 49.5 km (31 miles). In order to keep the acceleration to within approx 6 g's, we need about 33 seconds of acceleration, during which time we travel about 33km (about 20 miles). 20 miles of infrastructure is too much to put even on a mountain side in L.A., so we have to do better. If we put the passengers into a water-filled container, we might be able to do 12 g's, which would reduce the acceleration distance to perhaps 10 miles, which would be easily doable on Interstate 5 to the north of Los Angeles. A 'normal' landing would require slightly less acceleration in reverse due to the atmospheric losses on launching and landing. An 'abnormal' landing would require a parachute, and would happen if the onboard computers decided that it would be impossible to land safely in the 'receiver'. Here's why it is a 'loop'. At the receiving end (Mt Tam?), the projectile comes in and starts pushing air through a tunnel to the SF-to-LA launcher. This air is 20% oxygen, and it will get very hot, very quickly. We now inject some fuel -- e.g., diesel fuel, liquid natural gas, etc. -- into this air. We carefully select the amount of injected fuel to simply make up for the lasses in the system. The incoming projectile thus transfers its momentum & energy to the outgoing projectile, with enough added energy to make up for the losses, and the SF-to-LA projectile is now on its way. Yes, you get a little wet & have to take a shower when you arrive in SF, but if you are subjected to 12g's for 16.4 secs on launching and 16.4 secs on landing, you'll probably wet yourself anyway. Total time, including showers: 30-45 minutes. _No_ infrastructure required, except at the launching & receiving ends. Forget SpaceX; this will be the real E-ticket ride at Six Flags Magic Mountain (off I5 north of LA). Needless to say, the noise outside will be incredible, both on launching and landing.

3 3

[math-fun] rationalize exp(%i*x), for floating point x.
by Henry Baker 16 Aug '13

16 Aug '13

I guess this is a continuation of my rant of one year ago re rationalizing a complex number instead of rationalizing its real & imaginary parts separately. I'm interested in approximations to exp(%i*x), for real floating point x, but it is essential that cabs() of the result is identically 1. One way this can be done is s = rationalize(sin(x/2)), c = rationalize(cos(x/2)) z = ((c^2-s^2) + %i*2*c*s)/(c^2+s^2) (clear factions with 'factor'). We can compute the accuracy of this approximation by xp = atan2(2*c*s,c^2-s^2) and compare xp with x. Unfortunately, unless the denominators get pretty large, x isn't all that close to xp (considering the worse case error around the unit circle). Can anyone think of a better method?

9 15

Re: [math-fun] rationalize exp(%i*x), for floating point x.
by Adam P. Goucher 16 Aug '13

16 Aug '13

> Dan Asimov wrote: > > That's a beautiful and intriguing map of the Moon that Fred posted. Those areas of avoidance almost look like parts of a Petri dish where antibiotics keep a mold from growing. It looks as if it would take a lot of mathematical explaining to understands why it looks that way. You get the same phenomenon in the algebraics, and indeed in the rationals (c.f. Ford circles). I think that the proof is essentially the same as showing that numbers with fast-growing convergents (e.g. Liouville's number) are transcendental. See, for example, this Wikipedia image: http://upload.wikimedia.org/wikipedia/en/d/d1/Algebraicszoom.png Sincerely, Adam P. Goucher http://cp4space.wordpress.com

3 2