Silver describes his prediction methodology on his blog. I’ve implemented a rough version of it in Python, with placeholders for things I haven’t done yet. Code and polling data are available on github (vedant/election-prediction.git). Polling data are scraped from Real Clear Politics. Try modifying and augmenting it to generate your own projections.

This implementation predicts 303 electoral college votes for President Obama, to 235 for Governor Romney, and generated the electoral college map below. This is close to Silver’s current projection of 305 to 232.

The model implemented here gives an exponentially decaying weight to older polls, but doesn’t consider poll sample size or historical pollster ratings. I expect that neither of these is especially important when using the RealClearPolitics polling data, which seems to include only major polls. The implementation also drops historically unreliable pollsters, and provides for dropping partisan polls and making adjustments to polls that have historically leaned to one side.

There is currently no trendline adjustment to account for the recent propensity of the electorate, and no likely voter adjustment or non-poll data, all of which are included in Nate Silver’s model.

The result of this implementation is probably only close to Nate Silver’s actual methodology because there is extensive polling data for the presidential election. I imagine the more sophisticated model components only play a significant role in Nate Silver’s model when polling data is more sparse and less consistent.

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 and hackernews.

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.