I work on econophysics, which he basically invented, so I encounter his papers regularly. After seeing a few dozen of his econophysics papers, their titles start to blur together. This is no surprise—he has published so much in econophysics that many of the same terms appear in his paper titles.

So I wrote a Markov title generator and trained it on Gene Stanley’s econophysics papers to see if it could generate Stanleyesque paper titles. See for yourself:

The Distribution of Commodity Price Fluctuations.
Correlation in Complex Organizations.
Scaling Behavior in the Random Matrix Theory Approach to the Indian Stock Index.
Statistical Regularities in Stock Prices.

I would totally read these papers. Some of them even sound pretty interesting. Sadly, they don’t actually exist.

Try generating your own paper titles with this python library I wrote. It generates chains of arbitrary length and is optimized for clarity and not speed, and it’s based on shabda’s on agiliq.com.

When called from the command line, it’ll scrape titles from Google Scholar if you feed it an author name as a command line argument. So

python markov.py "HE Stanley"

will scrape 300 of Stanley’s paper titles as the source corpus. This works best when the author name is provided as first and middle initials and a last name, as shown. Caution: scraping Google scholar violates their TOS.

If you’re using a small corpus and long Markov chains, you’ll end up with lots of actual strings from the corpus, and no fake ones. If this happens, experiment with the second parameter to the constructor for the class “MarkovGenerator.”

See also SCIgen, which generates entire papers, but cannot be seeded with a particular author or category.

Code on github.

See comments on HackerNews.

Manufacturers tend to use slightly different algorithms and treat them as trade secrets. But in practice, their algorithms are similar, because the theoretical optimization criteria are roughly the same:

• provide even service to each floor
• minimize how long passengers wait for an elevator to arrive
• minimize how long passengers spend to get to their destination floor
• serve as many passengers as possible

The single elevator case is not very interesting, nor is the case when the passenger can’t specify his direction of travel when making the call (one button per floor), so I’ll instead discuss only the case where there are multiple elevators, and two buttons on each floor.

There are many criteria to consider in elevator scheduling. For example, people have predictable behavioral patterns that must be addressed, including the uppeak and downpeak—respectively 9AM and 5PM, in many office buildings—which are when elevator efficiency matters the most. There is often a 1-2 hour two-way peak (lunchtime) to address as well. Algorithms should consider whether an elevator is full before assigning it to an elevator call. Sometimes, some blocks of floors have predictably higher interblock or intrablock traffic than other blocks. Often, calls on some floors (executive floors, for example) are given higher priority than others (basements). All of these factors increase the algorithm sophistication.

Still, they tend to be based on the four classic group traffic control algorithms.

• Nearest Car (NC): Elevator calls are assigned to the elevator best placed to answer that call according to three criteria that are used to compute a figure of suitability (FS) for each elevator. (1) If an elevator is moving towards a call, and the call is in the same direction, FS = (N + 2) – d, where N is one less than the number of floors in the building, and d is the distance in floors between the elevator and the passenger call. (2) If the elevator is moving towards the call, but the call is in the opposite direction, FS = (N + 1) – d. (3) If the elevator is moving away from the point of call, FS = 1. The elevator with the highest FS for each call is sent to answer it. The search for the “nearest car” is performed continuously until each call is serviced.
• Fixed Sectoring Common Sector System (FSO): The building is divided into as many sectors as there are elevators. Elevators in each sector prefer calls in that sector.
• Fixed Sectoring Priority Timed System (FS4): The building is divided into up sectors and down sectors, and elevators only ever treat down calls in down sectors and up calls in up sectors. Each sector has a priority level, which increases the longer the passengers wait. The rate of increase can vary from sector to sector and over time.
• Dynamic Sectoring System (DS): Floors are grouped into dynamic sectors. Each elevator is allocated to a sector in the sector definition, and the sectors change size and location based on the position of moving and idle elevators.

Modern control systems do even more than this. Some of them dynamically compute cost functions for passengers waiting on an elevator. Stochastic traffic control systems empirically compute the distribution of response times and try to make it as Gaussian as possible (wait times should be consistent; there shouldn’t be some times when elevators respond instantly and others where they take a while). Some advanced techniques use fuzzy logic schedulers (Ho and Robertson 1994), genetic algorithms (Siikonen 2001, Miravete 1999), and neural networks (Barney and Imrak 2001).

Most of this information is paraphrased from UK-based lift consultant Gina Barney’s book “Elevator Traffic Handbook: Theory and Practice.” A most uplifting read.

This post originated as an answer on Quora.

See discussion on reddit, hackernews, and twitter.

Short answer: no.

Rage Against the Cage (RAtC) exploits the fact that the Android Debug Bridge daemon (adb) on Android devices starts as root by default, and calls setuid to drop its privileges to those of a shell account.  The ADB daemon is what runs on Android phones to enable Android software developers to communicate with the phones they’re testing their software on.  This kind of issue doesn’t exist in Linux in general, so the exploit probably can’t be generalized.  Nonetheless, here is some more detail on how RAtC works.

In Linux, a system-wide resource limit, RLIMIT_NPROC, defines the maximum number of simultaneous processes allowed by the system (Android, in this case). RAtC checks this limit, and spawns processes that do nothing until Android’s limit is reached. This is called a fork bomb.

With the number of processes maxed out, RAtC kills the running adb process on the phone. The process that starts adb when the phone is turned on tries to ensure that adb is always running, so it restarts adb.  There’s a race condition for that parent process to overcome here, because the adb process must be spawned while RLIMIT_NPROC is already nearly maxed out.

Adb restarts by default as root, which it needs to do so that developers can properly debug their software. It then quickly checks if it does indeed need to keep running as root, or if it can downgrade its privileges because root access isn’t necessary. The former is only true when Android is running in a sandboxed emulator on a developer’s computer or if the Android build is a debugging version, so it tries to drop its privileges using setuid.

But RAtC’s fork bomb has already maxed out the number of processes already running, so the call to setuid fails, and adb keeps running as root. With adb running as root, we can do whatever we want on the device.

This is also a post on Quora.

Here’s the page on NECSI’s website.

Here are reddit posts about it in economics, politics, math, finance, and occupywallstreet.  Here’s an HN post about it.

It was covered by BoingBoing, PhysOrg, ScienceNews, Technology Review, ZeroHedge, Naked Capitalism, and others.

One hypothesis to explain why “trendy” names attract revulsion is that one is likely to have experienced a greater degree of immaturity with younger people, and people with trendy names might be of lower average age than people with more traditional names. That is, trendy names might map more strongly to a younger part of the age spectrum. Wolfram Alpha confirms that people with trendy names are younger, on average:


I wanted to quantify that intuition by generating a set of names that is “trendy” by some statistical measure using the Social Security Administration’s names database, which contains time series of the number of children born in the US with each given name. I picked an arbitrary trendy-sounding name—”Brody”—and identified names with which its time series had the highest correlation. Below are the time series, normalized by max value and smoothed in a three year window, for the 50 names most highly correlated with “Brody”. The darkest line is “Brody,” with lighter lines subsequently less correlated.
What are the least correlated names? Are they Biblical names? Are they names that sound “classical?” Here are their time series, also normalized by max value and smoothed in a three year window:

These names seem to experience a surge of interest in the late 1800s, followed by a dip in the early 20th century; then they peak out around 1920, and wane steadily in popularity to the present day, to the point that they are all quite unpopular. Here are the names themselves:

The names at right aren’t Biblical, but they do sound really old. They’re also all female names, which suggests that a better analysis would consider male and female names separately.

Code is available here.
Data is available here.

If you can score competitively on the SEAL Physical Screening test — that is, if you can swim 500 yards in 10 minutes, do around 80 pushups in 2 minutes, 80 sit-ups in 2 minutes, 11 pullups from a dead hang, and run 1.5 miles in boots in under 10:20 — you ‘ll be assigned to  BUD/S, the “Basic Underwater Demolition/SEAL” course.

BUD/S is a 28-week course comprised of three phases. First, a three week indoctrination program.  Then, seven weeks of physical conditioning that includes navigating the Pacific surf in inflatable boats, ocean swims, timed 4 mile runs in soft sand, and “hell week,” a 132-hour period of continuous physical activity (with 4 hours of sleep). Then an eight week diving course, and a ten week land warfare course.  Fewer than 20% of those who start BUD/S make it through.

Next, a 26-week course called “SQT,” Seal Qualification Training, consisting of Survival, Evasion, Resistance, and Escape training; tactical air operations; combat medicine; communications; cold weather mountaineering; combat swimming; land warfare; unarmed combat; and close weapons combat.  Most of those who make it through BUD/S also make it through SQT.

Welcome to the Navy SEALs, where you’ll be one of around 2,400 men in one of 9 teams, numbered 1-5 and 7-10.  Perform impressively over the next several years of deployments—roughly until your mid 30s—and you stand a chance of being recruited to the Naval Special Warfare Development Group (DEVGRU), AKA “Team Six.”  The selection process is classified.  If you consistently perform at the highest level while in the SEALs, you’ll enter a half-year training course.  Several SEAL operators have been killed during parachute accidents and close-quarters battle training accidents in this phase of  training.  If you make it through, welcome to Team Six.

You’re now a member of one of the most selective fighting forces in the world. Your unit responds directly to the President and to the  Joint Special Operations Command‘s Special Mission Unit.  But we’re not done yet.  Team Six consists of roughly 200-400 operators in three combat teams and three support teams.  You can’t end up in the support teams or on the two standard Assault teams.  You need to be in the Premier assault team, which consists of some 80 operators. You’ll have to distinguish yourself in armed combat and assault tactics to get into the Premier assault team.

Still not done.  The assault team in Operation Neptune’s Spear was 24 operators.  So you’ll need to distinguish yourself further within the Premier Assault Team to make the cut.

24 operators out of 79 Premier assault team members out of ~300 DEVGRU operators out of ~2,400 SEALs.  A selection rate of 1% after a selection rate of 20% (to get into the SEALs) after a selection rate of 50% (to enter the Navy).  Yikes.

Let’s look at how this intuition might have been used to find Osama bin Laden.

First, let’s formulate scenarios about bin Laden’s status.  Suppose that experts’ opinions indicate that, with the probabilities shown, he’s either

• Able, and actively running Al-Qaeda: 20%
• Able, but in hiding, and passively involved with Al-Qaeda: 30%
• Receiving dialysis treatment in a hospital: 30%
• Alive, but doing something else: 10%
• Dead: 10%

To decide where to search, we want to determine where he’s likely to be in each of these scenarios.  We’ll define a discrete search space by saying that we expect bin Laden to be in each of these places with the probabilities shown:

• Karachi: 10%
• Islamabad: 10%
• Lahore: 10%
• Elsewhere in Pakistan: 50%
• Outside of Pakistan: 20%

Next we want to define conditional probabilities that he is in each of these locations given each of the above scenarios. For example, If he’s dead, finding him in, say, Islamabad, will be near impossible. In other words,

because his body may have already been buried or destroyed.  Consider what actually turned out to be the case — he was (effectively) in Islamabad, and was able, but in hiding.  Bayes’ theorem tells us that

Where is a “Location”, and is a “Scenario.”  The probability of finding bin Laden in Islamabad, given that he’s able but in hiding, might then be:

If we compute this probability for each location for each scenario, we have a set of probabilities that we can use to define a search path that starts at the point of highest probability and moves to lower probability areas.  If we had three locations, and three “likelihood classes” of finding bin Laden in each of them, we’d have a histogram like this one:

Probabilities in discrete space. One axis is "Locations," the other is "Likelihood of finding"

Information we gather during the search might be used to revise probabilities during the search.  For instance, we might receive new intel while searching Lahore that decreases the probability that bin Laden is dead, which forces us to recompute all conditional probabilities in which we depended on .