As several others have suggested, the elevator should behave differently at different times throughout day.
A smart elevator algorithm would adapt to the arrival behavior of people in a building through some clever stochastic simulation and modeling. For example, a simple model that could work quite well is to optimize for (read: minimize) the average time any passenger would wait for an elevator to arrive. But to do this, we need to model how frequently people request an elevator on each floor over the course of the day.
Modeling elevator requests
- We can assume that the number of people who request the elevator on each floor is a Poisson process with a mean of n. On a representative day (i.e. for an office building, choose a weekday), we can observe the number of people who arrive at the elevator each hour. This data would drop in as the n in our Poisson arrival processes.
Computing optimal solutions
- Using a statistical library, we can start generating simulated arrival data and apply integer optimization algorithms to determine which floor the elevator should rest on when there are no elevator requests, for each hour of the day.
Thanks for pointing that out. We probably haven't fully processed a single image from your queue yet, so sorry about the confusing circle it's throwing you in during that case... will fix on our end
There's a lot more than that meets the eye happening beneath the surface. When you have a thousand photos up there, you'll get a better feel of our algorithmic clustering.
Agreed. To clarify my previous point: when technologists work in supporting roles to businesses, the business-people-first management hierarchy mostly makes sense. After all, the parent business is the end customer.
Where engineers feel most repressed is when they are the ones directly making money for the company, but are being taken advantage of by "business people" who aren't making the company money.
You're right -- the people who work on products that makes the company directly are generally treated (and compensated) better at good companies. Imagine if these same engineers weren't treated well... I doubt they'd have much respect for their business-y colleagues/bosses.
I once read an article that discussed these tensions in excruciating detail. Below is the general gist of it from memory.
A potential cause of the rift between (software) engineers and business people could do with how each group attempts to optimize for returns in their work.
In an ideal world, a software engineer aspires to write elegant code just once, then deploy their work on as many systems as possible (for installed software), to as many users as possible. The software engineer's dream:
1) write code once
2) profit off it indefinitely
3) scale up profits by running the program on as many computers (or for as many users) as possible.
In a "business person's" ideal world, they would come up with a magical process that prints money that is easy to rinse and repeat. A good example is the fast-food franchise model. The business person's dream:
1) come up with a repeatable money-making process
2) profit off it indefinitely
3) scale up profits by running the process with as many people as possible, in as many places as possible.
Before software became big business, business people and software engineers probably got along just fine. I'm guessing it was because most software engineers (or programmers at the time) played a mostly supporting role to the core business of these big blue chip companies. For example, they might be writing software to help cut costs or improve operations efficiency at a large manufacturing company.
Then software itself became a moneymaking business. Now software engineers were optimizing their work input to maximize profits by exploiting computer cycles. All the while, some of these "business people" in software companies came from the traditional school of thought. So they were optimizing to maximize profits by exploiting human cycles (basically employees, and this included software engineers). If anyone didn't want to be treated like a computer program, it was the software engineers. You can probably see where this is going -- this led to a point of contention, or power struggle, between the engineers and business folks.
P.S. If anyone has a link to the article I was referring to please do share!
IMO, the "worse-is-better" approach is especially applicable to startups in the sense that during its first few iterations, you (the founders) don't know exactly what-to-build. Hence, the definition of "completeness" in the scope of your product is fuzzy at best.
Once the idea of "completeness" is crystallized (based on listening to what people want), I think that's when it's a good idea to build it right.
By "building it right", I don't mean to pay the same amount of attention to all features for the sake of completeness. Here, I'm a proponent of the 80/20 rule. Specifically, that the important 80% of the features be implemented first. That doesn't mean ignoring the remaining 20%, just that the rest of it will need to be hashed out later/eventually. An 80% product is enough for a demo/risk-loving early adopters, but ultimately customers want to pay for 90%-100% products.
Very apt that you brought up Steven Strogatz. I took Prof. Strogatz's calculus for engineers class back in college (Spring 2004). If you like the way he discusses math curiousities in his NYTimes column, you'll surely enjoy his lectures as well!
In my life at least, it's been rare to come across a math professor/educator who pushes harder for understanding (connecting the dots) rather than knowledge (disjointed lists of equations and theorems). Mathematicians' laments aside, inspired teachers are already changing the way that some students -- albeit a small minority -- view the field of mathematics.
Back in college a few years ago, we mostly used Simplex and other tableau-pivot based algorithms for solving large linear programming problems. Link to wikipedia article on the Simplex algorithm http://en.wikipedia.org/wiki/Simplex_algorithm
For most problems that individuals face each day, linear programs are fairly simple to model and solve. However, there are lots of complex problems that are solved each day.
A few examples of large-scale linear programming problems:
- For Amazon.com: what quantity of each item should be stocked at each warehouse each day to minimize inventory while also optimizing for shipping time and cost to demand nodes (customers).
- For an airline: how to plan and schedule flights to all domestic and international airports to maximize profit
- In shipping logistics: how to allocate trucks and set routes to minimize fuel cost while satisfying delivery time.
For complex systems, you can easily run up a linear program with millions of independent variables (producing millions of rows in the linear system).
I've only used craigslist (on the consumer side) while apartment hunting... With that said, but if I were to add a listing, it would makes sense (and be in my advantage) to track the effectiveness of my listings and optimize them for traffic and conversions