Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So You Think You Can Program an Elevator

github.com

Post reply on HN
Print view View original

21–30 of 118 posts

Re: So You Think You Can Program an Elevator

#21

Post by noir_lord »

arnarbi wrote: post #14

This was was posed as the the first homework assignment in my first undergrad CS class (15 years ago). I don't think a single person managed to do it. It's a classic example of a problem that you think is appropriate to throw at new programmers but find out it goes terribly wrong because the hard part is designing a suitable state machine first. If you just start coding without a full model that covers all the edge c…

That actually seems like the perfect first programming problem (after some syntax), an appreciation of how seemingly simple problems can blow up in your face is a nice intro to a career in software anyway :).

Re: So You Think You Can Program an Elevator

#22

Post by phasmantistes »

This is both cool and disappointing. I'm sure this is more challenging than it looks, and it's cool to see emergent complexity from a (seemingly) simply set of conditions to satisfy.

However, the reason I think about elevator programming isn't to make an elevator behave the way they do today. It's to make an elevator behave better than they do today.

For example:

* I don't want an elevator to close and reopen its doors on the same floor. That's horrible user experience.

* All the interesting problems arise when there are multiple elevators servicing the same set of floors. So let's control more than one elevator at the same time.

* If the elevator is on the ground floor, and has downward calls on both the 1st and 20th floors, then it is likely more efficient to service the 1st floor first rather than bypassing them just so you can keep travelling in the same direction.

I'd like to see a version of this that, rather than enforcing arbitrary rules, just has a lot of series of inputs and lets people compete to service those inputs in the shortest number of steps.

Re: So You Think You Can Program an Elevator

#23

Post by Cshelton »

noir_lord wrote: post #4

Very similar immediately playable JavaScript version. http://play.elevatorsaga.com/ Which I'm now closing as I lost too much time to this the first time I saw it.

This is awesome, I'm closing it now though as well.

This is how teaching should be...this exercise isn't at all about programming and more about how to think. This can be simplified into a drag and drop block language and given to grade school kids as a really good exercise.

Many programmers in the professional world today would really struggle with this because they never learned to actually think, they just "program" (copy paste, edit work already done by others). They don't actually create new things or find solutions themselves.

Re: So You Think You Can Program an Elevator

#24

Post by The_Magistrate »

Zikes wrote: post #8
n0us wrote: post #2

Then there is the alternative system where you do not request UP or DOWN but you request the floor, otherwise known as destination dispatch https://en.wikipedia.org/wiki/Destination_dispatch which introduces a whole new set of complexity.

I think I read once that when elevators still had operators, larger buildings would have one or more dispatch agents in the lobby that would line people up at the appropriate elevator for the range of floors they intended to visit.

Taller buildings with complex and highly trafficked elevators still do this only using electronics. Employees swipe their badges at a podium which reads what floor they work on and indicates which elevator they should proceed to. The system can intelligently schedule the elevator for that person to use knowing where their destination is.

Re: So You Think You Can Program an Elevator

#27

Post by verbatim »

n0us wrote: post #2

Then there is the alternative system where you do not request UP or DOWN but you request the floor, otherwise known as destination dispatch https://en.wikipedia.org/wiki/Destination_dispatch which introduces a whole new set of complexity.

As a programmer who works in a building with one of these -- I've often been quite sure I could code a more efficient system.

It would be pretty fun if someone were to make a version that supported this. :)

Re: So You Think You Can Program an Elevator

#29

Post by tsunamifury »

Cshelton wrote: post #23
noir_lord wrote: post #4

Very similar immediately playable JavaScript version. http://play.elevatorsaga.com/ Which I'm now closing as I lost too much time to this the first time I saw it.

This is awesome, I'm closing it now though as well. This is how teaching should be...this exercise isn't at all about programming and more about how to think. This can be simplified into a drag and drop block language and given to grade school kids as a really good exercise. Many programmers in the professional world today would really struggle with this because they never learned to actually think, they just "progra…

Plenty of programmers think, they just don't consider the use case and the user.

Re: So You Think You Can Program an Elevator

#30

Post by neil_s »

phasmantistes wrote: post #22

This is both cool and disappointing. I'm sure this is more challenging than it looks, and it's cool to see emergent complexity from a (seemingly) simply set of conditions to satisfy. However, the reason I think about elevator programming isn't to make an elevator behave the way they do today. It's to make an elevator behave better than they do today. For example: * I don't want an elevator to close and reopen its doo…

THIS.

However, the criterion you're optimizing for is still unclear. Should it be: a) the total number of steps the elevator takes b) the average number of steps each user has to wait c) the maximum number of steps each user has to wait d) the 90th percentile of user waiting steps

Note: here, I'm counting the steps spent waiting for an elevator as well as the steps spent in the elevator till the destination as the same, but presumably you'd want to count steps spent inside the elevator as costlier, further complicating matters.

And this not even considering what happens if your algorithm answers 20 calls, without going to any destination floors, when the elevator capacity is only 10 people.

That's what makes this such an interesting problem.

Post reply on HN