News for hackers. Stuff that matters.

emonidi

Re:So You Think You Can Program an Elevator on Wednesday January 13, 2016 @03:40PM (#10897315)
I guess we are looking at a trade-off in every case. Is speed, waiting time, or moves(energy saving) your priority. When you order a set of six to eight elevators for a 70 story building you probably are allowed to set your preferences of how your elevators want to perform. This is why I could not get constant (100%) success rate with one universal algorithm. I always had to change something.
Re:So You Think You Can Program an Elevator on Wednesday January 13, 2016 @03:36PM (#10897291)
I am also stuck at number ten. There is a link "Wiki and solutions" in which I guess we could find some useful theory. Still haven't taken a look at it.
Re:So You Think You Can Program an Elevator on Wednesday January 13, 2016 @03:35PM (#10897276)
Obviously you did not reach the level when you can program the behaviour of four elevators in the same time :) About the first and the 20th floor: How about if you've got 15 people on the 20th floor and one person on the 1st? Every button press is a request that could add more weight to the particular floor. After all the goal is to transport as many people as possible for a given time.
Re:So You Think You Can Program an Elevator on Wednesday January 13, 2016 @03:31PM (#10897248)
1. Because maybe the author wanted to keep the property hidden and only expose a getter function and hide the setter? 2. Same reason. They are being set internally. A sane programmer would not give you the power to do that because its a product of internal calculations. 3. Naming of method/function and variables is the second hardest thing in programming :) 4. The callback of on.('floor_button_pressed') gives you an floorNumber argument which is more than sufficient. What event in real life would you describe with on('in-droor-button-press') ?