> Destination Dispatch [...] are in general worse
I wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be:
- Everyone who is not on the ground floor generally want to go to the ground floor.
- People who are on the ground floor generally travel in large groups to the same destination.
This happens because people who worked on the same floor often leave for lunch at the same time, and return at the same time to the same floor. Destination Dispatch helps in this case because it's batching large groups of people with the same destination.
Yes, it's definitely more likely for an individual already in an upper floor to return to ground than a stop above or below. The people queuing up in simulations don't seemingly get this right all the time.
Also the group of people going to or returning from lunch is real as well. The grouping factor happens more at the middle of the day and less at the morning or evening. Primarily because of lunch.
Is it because the criteria is wait time not travel time? Destination dispatch would avoid some extra stops on the trip.
I just visited a new building with destination dispatch, so it seems to be still around.
My EE roommate in college had to build an elevator circuit as a final problem. It was on a bread board and had a bunch of call buttons and had a motor and a clear disk with black squares so it could figure out where it was…. I think it was the simple algorithm…
It very well could be the case that people get more upset about waiting for the car than total travel time when they are already in the car. Ie, pick them up sooner even if travel time is longer. In fact, I would bet that this is the case.
Having chatted with friends who have gotten stuck in elevators, you definitely should care about total travel time.
In one case, the building was still being commissioned and it took a while for anyone to even realize they were stuck (could spawn a whole discussion about launch processes in itself).
It should be both, I think. Same goes for queuing in the restaurant. Waiting for the table for 5 minutes, then 5 minutes for the waiter, then 10 minutes for the drink, then 25 for the food is better than waiting for the table for 25 and then getting your full order in another 5.
Basically you have an irrational sense of progress even if things get delayed
The criteria might also be throughput. That is moving maximum number of passengers in which case total travel time is likely much better metric than wait time.
Surely there's a dataset out there with elevator calls for an office building you could test on, instead of the poor random destination case.
Surprisingly, claude failed to find a good one.
Also, part of destination dispatch (I'm guessing based on experience) removes the 'stopping on every floor problem', so the real test would be total time including wait at that point I think.
I think most of these sort of data sets are considered trade secrets. They are certainly recorded and even stored. But as they could give competitive edge between manufacturers they are not publicly shared. And access to them would mean building maintenance or managers giving access to their occupants information which some of the occupants would not like.
Yeah, and definitely is not the right story for hotels. His premise of "morning traffic mostly from lobby to floors" is completely false in an hotel where you get it both ways due to people going down for breakfast and going back up and the down once again.
I see hotels with the kiosk model changing the UI depending on breakfast rush hour
Most interesting hotel elevator system I’ve seen was in Washington DC.
Instead of hitting the call button, you started the request with your floor. Then the system would assign you an elevator (there were 6 cars as I recall).
I assume this gave the system more accurate routing data to make it more efficient for everyone.
> Yeah, and definitely is not the right story for hotels.
The first time I encountered Destination Dispatch was in a London hotel, maybe 15 years ago. Anyone unfamiliar with the system would naturally sprint towards an open elevator and end up in an elevator with no buttons, totally bewildered. It's not the right system for a transient population.
Cruise ships that use destination dispatch have been much nicer too. Ships that use the older algorithms are a pain to wait during peak times. Guess plus side you’ll use the stairs more.
This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing.
Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonder if this actually happens, though.
I want to own something here: this is the fourth time in a row I’ve brought you to the 29th floor when you asked for the third. I am creating a memory to always go to the 3rd floor instead of the 29th, which should prevent this from happening again.
Then it'll be time to make an entirely new software accreditation system, simply so that anyone building such a thing can be disbarred/excommunicated.
Most likely not. I think all the big players have been using more traditional ML approaches for years. Then again someone new might go there and fail miserably.
This is an industry that evolves extremely slowly. A decade back one of the big players in this space was still using a software emulation of their original hardware relay logic, because it was cheaper than retraining all the technicians...
It is just the reality that LLMs are not superior for this purpose. They are most likely very much inferior. There is no need to use language models for something that involve no language.
I feel weirded each time LLMs are suggested for anything as some sort of holy solution for every single problem. Robot surgery let LLM control it. Robots cooking LLMs. Nuclear power plants and oil refineries LLMs... Industry has find a sledge hammer and now everything is a nail...
The data is already there. This also gets more interesting when you expand the scope from just elevators to general building occupancy and movement.
In the simplest sense, I've seen this tied into security gates so as people badge on when entering the building there's already suitable elevator movement to meet demand by time the foot traffic reaches the lift lobby. That can then also feed into destination dispatch if you move from just people counts to identity (and known/most likely work floor).
From there you can move into wifi trilateration and have a live and quite accurate view of both how and who interacts with a physical space. This can feed into HVAC load shedding, JIT bookings for meeting rooms or workspaces, and a lot of very good things from a sustainability and general optimisation perspective. The flip side is it also has the potential to be an absolute dystopian privacy nightmare.
> (...) and a lot of very good things from a sustainability and general optimisation perspective. The flip side is it also has the potential to be an absolute dystopian privacy nightmare.
Privacy is an illusion for most people, and in office spaces, it's also a red herring. Wifi trilateration doesn't make things worse when you have a CCTV camera on every corner, badge reader at every other door, and presence sensing in conference rooms. Dystopia does not materialize without a severe regime shift.
Nah, my main worry is precisely sustainability and optimization, i.e. cost-cutting, because the more tools you give a business to optimize, and the more bullshit excuses ("sustainability! saving the planet!") you give a business, the worse the outcome is for users (here: employees). And a lot of that is doubly annoying, because it's counter-productive.
So what you have smart sensors in every room, and combine it with badge readers and wifi trilat and what not, and have smart auto-routing/rebooking algorithm: half the week, all conference rooms are always booked full, and yet somehow when you physically go and check, a good half sits empty, and it's apparently an impossible problem to solve.
So what the bathroom wall says, "with water-saving fixtures, we're using much less water in this building", and "we're now saving 2L water per flush". It's all bullshit, because those eco inventions mean I need to flush 3 times instead of once, and it means that I spend a minute washing my hands instead of 10 seconds - especially because both the soap and the dispenser are also optimized, so it takes 20 seconds to get enough soap on your hands, and then extra 20 seconds to get it off afterwards, because unlike normal people soap, it leaves your hands slippery for some reason.
And then they say "scientists said you can dry your hands with just 2 paper towels". At that point I'm getting red, because yes, I saw that TED talk 15 years ago too, and yes, it's total bullshit. Maybe it was true then, but the industry and the beancounters have value-optimized paper towels 15 times since that.
The generalization and summary of this rant is: slack is good. Happiness lives in slack. There is such thing as optimizing too much. Also the small, isolated systems under optimization, are in reality neither small nor isolated.
> The generalization and summary of this rant is: slack is good. Happiness lives in slack. There is such thing as optimizing too much. Also the small, isolated systems under optimization, are in reality neither small nor isolated.
Indeed, the Boimler Effect, amongst other things.
I see an analogy, Food : Malthusian catastrophe :: Money : No room for profit in an economy.
> The generalization and summary of this rant is: slack is good. Happiness lives in slack. There is such thing as optimizing too much. Also the small, isolated systems under optimization, are in reality neither small nor isolated.
Yeah there's a certain type of engineer mindset that loves the idea of optimizing things. But if you want to really optimize something, you have to carefully account for every single possible factor, situation, and use-case. Miss anything, and it's a much bigger disaster than saving 2% of whatever resource. It's rarely worth it.
Much better to treat the presumptions as a vague heuristic, make generous assumptions and add some slack, and call that good enough. Now there's probably enough slack to cover most of the edge cases you didn't think of, other things you based your original assumptions on changing under you, etc.
> Ideally a new elevator installation would have a trial period where they record usage
There's a tricky problem here: as a user, the first thing you do upon discovering a new elevator, especially if you expect to be using it regularly, is to observe how it behaves and adjust your own expectations/behavior to it.
Things are constantly changing. For example, a new building might have two or three tenants, so entire floors can be skipped. But then five years later, the whole building is full. I would bet that every new algorithm after LOOK is just differentiation in a competitive market.
It is almost certainly because of the way the simulation was performed:
It turns out these fancy kiosks are in general worse for wait times compared to the traditional good ol' up and down buttons. There are certainly edge cases when the kiosks can win out (extremely tall buildings with 8+ cars per elevator bank) but for the majority of cases, simple up down buttons reign supreme.
This counterintuitive result is all thanks to the rebalancing step where every 5 seconds, the system re-optimizes each elevator's path. The kiosk enforces rigidity, you must get in the assigned elevator.
There should be no way that only having more information results in a worse outcome. At minimum, you could ignore the extra information, and achieve the same results as using up and down buttons.
Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
> Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
I don't think it's possible to have destination dispatch AND update assignment together, in the real world.
- If the user clicks floor 26 and you tell them to wait at elevator G, you can't really tell them to move to F if it's taking too long.
- But if you don't tell them an elevator to wait at, then you'd need them to run around what is possibly like 5-8 elevators to find which one is going to their floor? That's obviously not realistic.
So then you're going to just have them get in the first one that opens? But then that's just the same as an up/down button.
That explanation is entirely inconsistent with sambellll's statement that when the user clicks a floor, the display tells them what elevator to take, and that elevator is then locked into going to that floor.
Also, I don't think that destination dispatch would work if the elevator didn't commit to going to the users's floor at the point the user got onboard. It may also stop at additional floors that weren't committed to when the user entered, and it may drop floors it was thinking of going to before it picked up the user (if the user onboard isn't going to those floors), but once the user gets onboard, that floor is a hard commitment.
Destination Dispatch should also allow you to better optimize total travel time rather than just wait time. Especially in the tall office building case you could have an elevator that skips straight to the top floor instead of having to stop for people to get off people all the time.
omoikane · · focus · HN ↗
I wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be:
- Everyone who is not on the ground floor generally want to go to the ground floor.
- People who are on the ground floor generally travel in large groups to the same destination.
This happens because people who worked on the same floor often leave for lunch at the same time, and return at the same time to the same floor. Destination Dispatch helps in this case because it's batching large groups of people with the same destination.
taftster · · focus · HN ↗
Also the group of people going to or returning from lunch is real as well. The grouping factor happens more at the middle of the day and less at the morning or evening. Primarily because of lunch.
acomjean · · focus · HN ↗
I just visited a new building with destination dispatch, so it seems to be still around.
My EE roommate in college had to build an elevator circuit as a final problem. It was on a bread board and had a bunch of call buttons and had a motor and a clear disk with black squares so it could figure out where it was…. I think it was the simple algorithm…
vova_hn2 · · focus · HN ↗
Yeah, it doesn't make any sense to optimize wait time instead of total time from pressing the button to reaching destination.
kadoban · · focus · HN ↗
esikich · · focus · HN ↗
donalhunt · · focus · HN ↗
In one case, the building was still being commissioned and it took a while for anyone to even realize they were stuck (could spawn a whole discussion about launch processes in itself).
esikich · · focus · HN ↗
Gabrys1 · · focus · HN ↗
Basically you have an irrational sense of progress even if things get delayed
Ekaros · · focus · HN ↗
ApolloFortyNine · · focus · HN ↗
Surprisingly, claude failed to find a good one.
Also, part of destination dispatch (I'm guessing based on experience) removes the 'stopping on every floor problem', so the real test would be total time including wait at that point I think.
Ekaros · · focus · HN ↗
darkwater · · focus · HN ↗
I see hotels with the kiosk model changing the UI depending on breakfast rush hour
whartung · · focus · HN ↗
Instead of hitting the call button, you started the request with your floor. Then the system would assign you an elevator (there were 6 cars as I recall).
I assume this gave the system more accurate routing data to make it more efficient for everyone.
nkjoep · · focus · HN ↗
icosian · · focus · HN ↗
The first time I encountered Destination Dispatch was in a London hotel, maybe 15 years ago. Anyone unfamiliar with the system would naturally sprint towards an open elevator and end up in an elevator with no buttons, totally bewildered. It's not the right system for a transient population.
donalhunt · · focus · HN ↗
Or should it be YORO? You only ride once?
alexpotato · · focus · HN ↗
I also thought that this is one of the biggest reasons destination dispatch was better.
There are even articles about switching to destination dispatch in office buildings or hotels lead to dramatic reductions in wait time.
dawnerd · · focus · HN ↗
pimlottc · · focus · HN ↗
Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonder if this actually happens, though.
shepherdjerred · · focus · HN ↗
fragmede · · focus · HN ↗
noisy_boy · · focus · HN ↗
brookst · · focus · HN ↗
breakingcups · · focus · HN ↗
ufmace · · focus · HN ↗
ArekDymalski · · focus · HN ↗
Terr_ · · focus · HN ↗
swiftcoder · · focus · HN ↗
Ekaros · · focus · HN ↗
swiftcoder · · focus · HN ↗
Ekaros · · focus · HN ↗
I feel weirded each time LLMs are suggested for anything as some sort of holy solution for every single problem. Robot surgery let LLM control it. Robots cooking LLMs. Nuclear power plants and oil refineries LLMs... Industry has find a sledge hammer and now everything is a nail...
omoikane · · focus · HN ↗
fuzzfactor · · focus · HN ↗
_kb · · focus · HN ↗
In the simplest sense, I've seen this tied into security gates so as people badge on when entering the building there's already suitable elevator movement to meet demand by time the foot traffic reaches the lift lobby. That can then also feed into destination dispatch if you move from just people counts to identity (and known/most likely work floor).
From there you can move into wifi trilateration and have a live and quite accurate view of both how and who interacts with a physical space. This can feed into HVAC load shedding, JIT bookings for meeting rooms or workspaces, and a lot of very good things from a sustainability and general optimisation perspective. The flip side is it also has the potential to be an absolute dystopian privacy nightmare.
TeMPOraL · · focus · HN ↗
Privacy is an illusion for most people, and in office spaces, it's also a red herring. Wifi trilateration doesn't make things worse when you have a CCTV camera on every corner, badge reader at every other door, and presence sensing in conference rooms. Dystopia does not materialize without a severe regime shift.
Nah, my main worry is precisely sustainability and optimization, i.e. cost-cutting, because the more tools you give a business to optimize, and the more bullshit excuses ("sustainability! saving the planet!") you give a business, the worse the outcome is for users (here: employees). And a lot of that is doubly annoying, because it's counter-productive.
So what you have smart sensors in every room, and combine it with badge readers and wifi trilat and what not, and have smart auto-routing/rebooking algorithm: half the week, all conference rooms are always booked full, and yet somehow when you physically go and check, a good half sits empty, and it's apparently an impossible problem to solve.
So what the bathroom wall says, "with water-saving fixtures, we're using much less water in this building", and "we're now saving 2L water per flush". It's all bullshit, because those eco inventions mean I need to flush 3 times instead of once, and it means that I spend a minute washing my hands instead of 10 seconds - especially because both the soap and the dispenser are also optimized, so it takes 20 seconds to get enough soap on your hands, and then extra 20 seconds to get it off afterwards, because unlike normal people soap, it leaves your hands slippery for some reason.
And then they say "scientists said you can dry your hands with just 2 paper towels". At that point I'm getting red, because yes, I saw that TED talk 15 years ago too, and yes, it's total bullshit. Maybe it was true then, but the industry and the beancounters have value-optimized paper towels 15 times since that.
The generalization and summary of this rant is: slack is good. Happiness lives in slack. There is such thing as optimizing too much. Also the small, isolated systems under optimization, are in reality neither small nor isolated.
ben_w · · focus · HN ↗
Indeed, the Boimler Effect, amongst other things.
I see an analogy, Food : Malthusian catastrophe :: Money : No room for profit in an economy.
ufmace · · focus · HN ↗
Yeah there's a certain type of engineer mindset that loves the idea of optimizing things. But if you want to really optimize something, you have to carefully account for every single possible factor, situation, and use-case. Miss anything, and it's a much bigger disaster than saving 2% of whatever resource. It's rarely worth it.
Much better to treat the presumptions as a vague heuristic, make generous assumptions and add some slack, and call that good enough. Now there's probably enough slack to cover most of the edge cases you didn't think of, other things you based your original assumptions on changing under you, etc.
TeMPOraL · · focus · HN ↗
There's a tricky problem here: as a user, the first thing you do upon discovering a new elevator, especially if you expect to be using it regularly, is to observe how it behaves and adjust your own expectations/behavior to it.
gpvos · · focus · HN ↗
razakel · · focus · HN ↗
mvkel · · focus · HN ↗
richk449 · · focus · HN ↗
It turns out these fancy kiosks are in general worse for wait times compared to the traditional good ol' up and down buttons. There are certainly edge cases when the kiosks can win out (extremely tall buildings with 8+ cars per elevator bank) but for the majority of cases, simple up down buttons reign supreme.
This counterintuitive result is all thanks to the rebalancing step where every 5 seconds, the system re-optimizes each elevator's path. The kiosk enforces rigidity, you must get in the assigned elevator.
There should be no way that only having more information results in a worse outcome. At minimum, you could ignore the extra information, and achieve the same results as using up and down buttons.
Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
sambellll · · focus · HN ↗
I don't think it's possible to have destination dispatch AND update assignment together, in the real world.
- If the user clicks floor 26 and you tell them to wait at elevator G, you can't really tell them to move to F if it's taking too long.
- But if you don't tell them an elevator to wait at, then you'd need them to run around what is possibly like 5-8 elevators to find which one is going to their floor? That's obviously not realistic.
So then you're going to just have them get in the first one that opens? But then that's just the same as an up/down button.
richk449 · · focus · HN ↗
Why not have active display above each elevator that says what floors it is going to when it opens?
NetMageSCW · · focus · HN ↗
richk449 · · focus · HN ↗
Also, I don't think that destination dispatch would work if the elevator didn't commit to going to the users's floor at the point the user got onboard. It may also stop at additional floors that weren't committed to when the user entered, and it may drop floors it was thinking of going to before it picked up the user (if the user onboard isn't going to those floors), but once the user gets onboard, that floor is a hard commitment.
account42 · · focus · HN ↗