One Cool Day Job: Building Algorithms For Elevators
McGruber writes "The Wall Street Journal has an article about Theresa Christy, a mathematician who develops algorithms for Otis Elevator Company, the world's largest manufacturer and maintainer of people-moving products including elevators, escalators and moving walkways. As an Otis research fellow, Ms. Christy writes strings of code that allow elevators to do essentially the greatest good for the most people — including the building's owner, who has to allocate considerable space for the concrete shafts that house the cars. Her work often involves watching computer simulation programs that replay elevator decision-making. 'I feel like I get paid to play videogames. I watch the simulation, and I see what happens, and I try to improve the score I am getting,' she says."
I've been looking for a more sophisticated follow-up to SimTower for a while now. I'd buy Otis Elevator Tycoon.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I expect the job has its ups and downs just like any other.
I'm guessing that the hardest part of the job is writing code that does not crash, possibly leaving elevator riders stranded between floors, or going up when they want to go down. Over the years Otis must have developed a pretty good elevator usage simulator that plays through millions of possible elevator use scenarios, and tries to find one that either crashes or confuses the system. If yes, the developers responsible for that "possibility simulator" should have been named in the article alongside "The Elevator Algorithm Lady". They should have gotten some credit where credit is due...
Why did the chicken cross the road? Because Elon Musk put an AI chip in its head.
Was a mathematician really needed for this job:
During the recent $550 million upgrade of the Empire State Building, Ms. Christy was asked whether she could help get more people up to the observation deck. She said she couldn't get more people into a car but could move them up more quickly. So she increased the elevators' speed by 20%, to 20 feet per second. Now the cars can rise 80 floors in about 48 seconds, 10 seconds faster than before.
Isn't making the elevator go faster a job for an engineer? Does one really need to be a mathematician to know that a faster elevator moves people faster?
I just realized something else, everyone would be playing with the elevator even more if it talked to you... so maybe it isn't a good thing to emit a sound... Maybe just call security.
God spoke to me
... say "I feel like I get paid to play videogames." That basically says "please cut my salary by $30,000.00"...
My less than symbol got nixed because it was thinking I meant hypertext markup
You are welcome to use this one: < (written as < - all four characters required.)
... when elevators can move in more than one plane: 10 PRINT CHR$ (205.5 + RND (1)); : GOTO 10
It must have been something you assimilated. . . .
That's an undergraduate level general optimization problem.
The one in TFA is a graduate level optimization under a particular set of data constraints. So the generally optimal algorithm for elevators has to a assume a random distribution of people to be picked up and destination floors (head is in a random location wants data from some other random location) - but in practice you may be need sequential access or the like. With elevators, I would expect that in mornings in residential buildings people want to empty out so the 'resting' point would to close to 2/3rds or 3/4ths of the way up, but in the evenings it would be the reverse direction, and business would be the reverse of residential. Schools have a somewhat more random use of bursty every hour up and down, and really big businesses may want dedicated elevators between floors shared by particular companies because there's a lot of daily movement within the floors of a company but not so much outside their area.
Lunch of course adds another complication.
There's a lot of neat work into simulating the data for a building that doesn't exist yet, or measuring the data for a building that exists but has a bad algorithm. And then trying to tailor your elevator to the specific behaviours that actually exist.
one certain Aerosmith song on it.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
Rumour has it that Otis have (or at least had) a UK office in the town of Reading (for our American cousins, the town is pronounced "Redding").
Their receptionist answered the phone with "Hello, Otis Reading?"
Multiple forced door closings when people hold the door open to chat.
Second most needed optimization:
Give me an ETA so I know when I'd be better off taking the stairs.
Most annoying feature that needs to be removed (some elevators):
If you'd manually hold the door for someone (those door open buttons are hard to find in a hurry sometimes. I believe there's even a paper on it), the door would then close v_e_r_y s_l_o_w_l_y while beeping reproachfully at you. The last thing I need first thing in the morning is passive-aggressiveness from a machine.
You will most commonly find it in large urban areas like NY and Chicago. In the Midwest where I worked in the elevator business, it's rarely a requested feature because folks aren't in such a rush in general.
"Do the Right Thing. It will gratify some people and astound the rest." - Mark Twain
Does it also simulate who farted?
Custom electronics and digital signage for your business: www.evcircuits.com
So the generally optimal algorithm for elevators has to a assume a random distribution of people to be picked up and destination floors
It seems to me that assuming a poisson distribution) or other random distribution, is a bad assumption. Passengers would be likely to arrive in clumps as meetings ended or buses arrived, and some destination floors would be far more popular than others
One thing that would help, but I have never seen, would be a way to cancel a button push (either the call button, or a floor button inside the elevator). Buttons are often pushed in error, resulting in wasted time.
I once heard a funny story about an engineer assigned to optimize an elevator system. The building supervisor had received numerous complaints about the elevator delays, so he told a young engineer to fix the problem. The engineer tried several adjustments, but still had just as many complaints. So he had mirrors installed next to each elevator, so people could adjust their hair, tie, clothing or whatever while they were waiting. Since people now had something to do while they were waiting, most of the complaints stopped.
Is that the resting place of the diskdrive head probably doesn't vary (like you describe for start of workday, lunch, & of course, quitting time - moving it to the most optimal spots during certain daily time periods).
Afaik? The HDD tends to try to keep the read-write heads in the CENTER of the disk (or rather, center of the filemass (moved to outermost fastest tracks with defraggers for fastest access/seek due to larger rotational diameters)).
You can't "move" the MFT$ (master file table) & certain other system files during usermode after all!
(At least NOT during usermode access to accomodate for times it *MIGHT* be different for differing work patterns (say you work @ home, & do your work the 1st 8 hours you wake up, & then the rest is family usage, your leisure, etc./et al)).
However, with NTFS & probably other modern filesystems?
MFT$ is placed in the MIDDLE of the "filemass" though for "optimality", since it's needed for file accesses of any kind (time of access stampings too, etc.) & then binary search patterns (like NTFS uses in b-tree seeks) do the rest!
I find this algorithm pretty amazing & VERY "common-sense", & that elevator algorithm & its variants, do one hell of a good job on QUEUEING UP REQUESTS, & then issuing them in the order the disk drive head passes over the areas concerned, in the most efficient order possible.
1 of its variants use 2 buffers (1 = currently being serviced requests, & 2 = upcoming requests to service): THIS seems like the smartest way to go about it imo @ least.
* Anyhow/anyways - I didn't think you were being a jerk, I hope you feel the same way regarding myself...
(Actually? I thought you offered some decent enough points, but you MUST ADMIT, the algorithms here are AMAZINGLY similar & I didn't SAY they were the "exact same" either)
Plus - I'd wager since the one for HDD's is named "Elevator Algorithm", the harddisk folks GOT THE IDEA from folks like this lady!
APK
P.S.=> Lastly - Sorry: Not "graduate level student"/postgrad/postdoc etc., in CSC!
I got the AAS 60 credit hours outta the way & went to work in the field as a programmer back in 1994 onwards!
(I've been "chipping away @ the stone" since then, & am 90/120 credit hours into the B.S. in CSC currently, taking coursework here and there as time & money permit)...
... apk
Elevator pseudocode is the heart of many a CS course. And CS courses were promised to be devoid of practical application.
Little known fact--if you are on a moving elevator and start to force the doors open, it will stop in between floors. Just don't try to get out when the elevator floor is high enough above a building floor that the shaft is exposed. How do I know? In the words of my roommate, I was shafted, literally -- fell into the shaft on the 14th and caught my self on the cables level with the 11th floor doors. My partner (in elevator hacking) quickly ran down the three flights of stairs, I was able to swing over, release the door catch and he opened the doors so I could swing out of the shaft...
As I was falling, my partner claims that he shouted "Nooooooo!", but I never heard him, I guess my reflexes were too busy getting a grip on the control cables?