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

Elevator Saga: An elevator programming game (2015)

play.elevatorsaga.com

Post reply on HN
Print view View original

71–80 of 103 posts

Re: Elevator Saga: An elevator programming game (2015)

#71

Post by nextlevelwizard »

7373737373 wrote: post #8
voldemort1968 wrote: post #6

I was thinking of creating this very thing on several occasions being in an elevator. The logic of elevators is very intriguing and more complicated than people realize.

I'm not sure if this is true. I think all elevators I've encountered followed the elevator/SCAN algorithm: > the elevator continues to travel in its current direction (up or down) until empty, stopping only to let individuals off or to pick up new individuals heading in the same direction. with the elevator staying on its last location if there are no new requests and there being no buffering time after a request, fi…

This works if you have only a single elevator, but if you have a group of elevators that work together and serve same set of floors you can start optimizing the trips for example journey time vs wait time.

Re: Elevator Saga: An elevator programming game (2015)

#72

Post by clarkmoody »

Jun8 wrote: post #15

Made me remember an interesting anecdote: During my PhD at Purdue I had the good luck to take the Pattern Recognition (nowadays would be called ML) course from Prof. Fukunaga, one of the pioneers in the field ( https://en.m.wikipedia.org/wiki/Keinosuke_Fukunaga ). In one of his classes he mentioned that years ago a company came to him, requesting his expertise in optimizing movement of a bank of elevators. He thought…

I pounded my head on this problem in a multi-agent system course in graduate school. Needless to say, I could not outperform a simple naive algorithm however hard I tried.

Re: Elevator Saga: An elevator programming game (2015)

#73

Post by Jun8 »

MobileVet wrote: post #39
Jun8 wrote: post #15

Made me remember an interesting anecdote: During my PhD at Purdue I had the good luck to take the Pattern Recognition (nowadays would be called ML) course from Prof. Fukunaga, one of the pioneers in the field ( https://en.m.wikipedia.org/wiki/Keinosuke_Fukunaga ). In one of his classes he mentioned that years ago a company came to him, requesting his expertise in optimizing movement of a bank of elevators. He thought…

Boiler Up! I had Prof Fukunaga for EE301 I think (Might have been EE202). I was too young and dumb to recognize his brilliance.

Awesome, it’s a small world. I was his teaching assistant during the times he taught EE301 (Signals & Systems) so chances are I’ve corrected your exams!

Re: Elevator Saga: An elevator programming game (2015)

#74

Post by templeos3 »

spicybright wrote: post #33
lucb1e wrote: post #32

Earlier quoted context omitted.

That's amazing. I'll be trying that trick next time I have some time to kill in a building! We also play the game sometimes of getting places we're not supposed to (as consultants). Walk around like you're from IT and are supposed to be there (technically both true), perhaps with a laptop under your arm, nobody will care what you do to any of the computers there. In schools and hospitals, and probably other places, t…

I'm sure for surgery rooms (at least), needing someone to rush in to help and having them fumble with ID cards outweighs a bad party trying to, I guess, muck up a surgery or something.

Very rarely do you have people rushing in to surgery rooms. Despite TV dramas, most surgeries are not high risk, most surgical patients are not critically ill, and those that are tend to be pre-staffed for the risk. OR rooms are not usually locked but the surgical suite sure is. The bigger issue with the surgical suite is proper attire. ICUs are a different matter (where coincidentally I happen to be tonight). Generally all the staff you need is already on the locked side of the unit.

Re: Elevator Saga: An elevator programming game (2015)

#75

Post by kqr »

em-bee wrote: post #43
asdfasgasdgasdg wrote: post #34

Earlier quoted context omitted.

Elevator could also make a decent guess at fullness just by recording the discrete changes in weight. It wouldn't be perfect but again it would probably be better than allowing user input.

i believe all elevators at least have a failsafe to refuse to run if they are overloaded. going from there to tracking and using the actual weight for its programming is not a big step

Oh, elevators know to some accuracy how many people-mass things are in it. It just rarely has reason to use that information.

Re: Elevator Saga: An elevator programming game (2015)

#76

Post by [deleted] »

em-bee wrote: post #42
ziptron wrote: post #29

I always wished elevator buttons could toggle. If you accidentally press the wrong floor, just press it again to cancel. This may not work in all situations, but in some situations, it could be a time saver.

our elevator does that, and i noticed it is quite common in chinese elevators. i can undo all destinations which makes the elevator just stop. living on the top floor of a highrise, i was occasionally able to use that when i realized that i forgot something at home (although most times it takes me longer to realize that than the elevator needs to make it all the way down) it is also very useful when the kids are naug…

[deleted]

Re: Elevator Saga: An elevator programming game (2015)

#77

Post by thesnide »

mcrae wrote: post #35
ziptron wrote: post #29

I always wished elevator buttons could toggle. If you accidentally press the wrong floor, just press it again to cancel. This may not work in all situations, but in some situations, it could be a time saver.

It works this way often in (north-east) Asia. Double-tap a selected floor and it unselects. Brilliant.

Yep. My office one does that. I first it was a joke, but it actually is indeed a brilliant scheme to avoid misclicks.

And as you seldom unselect, it's Huffman coding for the win ;-)

Re: Elevator Saga: An elevator programming game (2015)

#79

Post by gnramires »

An interesting improvement over naive operation I thought long ago: idle elevators should go to 1/2 maximum floor! You easily cut average wait times in 1/2!

Problem is, it's also energy inefficient. If you get a passenger at floor 1 or 0, you've wasted a lot of movement. On-demand movement wastes minimally.

So I've learned of a tradeoff between energy and waiting time -- not just elevator speed, but in algorithms.

It's fun to consider a minimal energy solution (it takes a very long time to get anywhere ;) ).

Re: Elevator Saga: An elevator programming game (2015)

#80

Post by tshaddox »

joshribakoff wrote: post #53
ziptron wrote: post #29

I always wished elevator buttons could toggle. If you accidentally press the wrong floor, just press it again to cancel. This may not work in all situations, but in some situations, it could be a time saver.

Many modern ones in high rise buildings require you to scan a key fob and/or enter the desired floor number, then it tells you which elevator to go wait at. The ones with the key fob often replace your previous selection automatically. There are not buttons in this style of elevator other than door open door close and call for help.

In an office building near me, the security person at reception enters a destination floor and tells you which elevator to step into. There are no controls outside or in the elevator (other than emergency stuff).
Post reply on HN