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
We can provide you virtually unlimited storage for your authoritative photo collection on our servers.
That is what I've been looking for, along with a way to have multiple computers "own" the photos and use them off of the local hard drive as needed (such as to order prints, etc.)
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.
There's at least some work by the algo to recognise different moments of the same day, I still need to upload more pictures to try to understand it correctly.
I understand but that's like saying you won't be using Google because they didn't explain the algo. Or you won't try the iPhone because they don't explain the algo that makes it scroll so gently. And so on.
It's free, you can try it if you really want. You can even use someone else's pictures. Asking for the algo seems too much.
As someone who runs another photo sharing site that organizes for you by date, I can say yes.
First, it's important to know that uploading a thousand photos is way easier on such a site, since you do no organizing work. Try uploading a thousand photos to Flickr without culling, organizing into albums, tagging and captioning, and see what your result looks like. It doesn't have to be like that.
Second, they have to be your photos for you to appreciate chronological organization. When I look at my own, I can say, "Wow, I just click 2005, then December and I see my Puerto Rico pictures. And I didn't have to organize them myself." You don't get the same effect looking at someone else's.
You need that many to understand the basics of the algo behind it? If that's how you debug your code than you might need to learn some better ways to do it...
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!
Everyone distrust business people, even other business people. It's that they (the stereotype) are so inherently driven by self-gain, so you always have to be wary that they won't use or backstab you.
Engineers on the other hand are usually more concerned with taking advantage of technology than of other people, so they're 'safer'.
Oddly enough, I usually hear this the other way around - that if you work on a product that makes the company money directly (shrinkwrap software for a software company, HFT shit for a financial firm, etc) that you'll generally be treated (and compensated) better than if you're in a supporting role.
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.
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.
(Disclaimer: I am a software engineer)
I think a lot of this attitude comes from lack of awareness of how the "business guys" do - indeed - make money for the company (even when the product is software.) It's easy for us techies to get so enraptured with the pure, raw technology that we miss the "other stuff" that matters; things like the fact that software doesn't jump off the shelf and sell itself to customers, the idea of assembling a "whole product," and how important that is to selling something, the importance of demand creation activities, the extent to which "business" functions like marketing and product management serve as a bridge between the customer and engineering, etc. If more of us engineers would look up and around and pay attention to what the biz guy and gals actually DO, and not just lean on tired old stereotypes, it would help a lot.
And, of course, the converse is true as well. Business folks don't necessarily understand what engineers do, and they also fall into thinking based on stereotypes.
In the end, we probably just need more dialogue between both groups and more shared understanding of the world around us.
The quintessential (business) terms for this are "profit center" and "cost center".
Next realize that the assignment of those terms is -- "standards" aside -- essentially arbitrary. One trick of senior managers "parachuted" in to "fix" things, is to start labeling things left and right as "cost centers". They then proceed with a -- very often, short-term -- plan to starve or kill them. Remember, their pay and bonus are dependent upon the next few quarters and not on long-term prospects.
Resulting advice: When you are in a "cost center", get out.
Great to see this in one place. I would love to know more about the more internal facing systems (code deployment, test frameworks, failover systems...).
