Forums Register Login

Elevator Simulator

+Pie Number of slices to send: Send
Hello,

I am developing an elevator simulator program using stacks. I have the program working except for one main problem. The elevator movements are based on the entrance floor of the next person who wants to get on the elevator rather than the elevator continuing in the direction it is going to unload current passengers at their desired exit floor. Does anyone have any advice on how I could accomplish this? I would not ask but I have been working at this for a long time.

For the move() method, I got the max exit floor of the current set of passengers and compared that to currentFloor, but the program gets totally messed up and I can’t follow what goes wrong. Maybe there is another way? Anyway, I hope this makes sense. Thanks for any tips you might have.


+Pie Number of slices to send: Send
Here is the other option that I tried for the move() method. The problem is it only works if I remove j-- from the load() method. But with j-- removed, if someone does not get pushed to the stack (because their entrance floor did not equal the currentFloor), they do not get evaluated again for loading once the elevator moves.

1
+Pie Number of slices to send: Send
hi Jaime,

I'm afraid you give us little to say anything wise about your problem. Can you supply us with working code thst we can test and see what is happening? (also called an SSCCE).

Meanwhile, if I look at your code I see a List of Persons, a MAX_NUMBER, and two stacks. Looking at your 'else' in line 52, that's the part where the code goes when personList[j].flloorEntered != currentFloor, the 'move' method is called, and the elevator starts moving. I'm unsure what the second parameter does. Anyway, the elevator moves one floor up or down, and what happens then?

So, I think you must elaborate a little. What does the personList represent? What is MAX_PERSONS, what about the Stacks and, most of all, how do you prevent the elevator making 'Brownse' movements when every new elevator passanger makes the elevator go up or down a floor?
1
+Pie Number of slices to send: Send
These names are not intuitive; they don't give other people a sense of their purpose/intent:

PersonStackElevator ePersonStack - what does the "e" prefix stand for?
lPersonStack - what does the "l" prefix stand for?

Why are ePersonStack, lPersonStack, and personList declared as instance variables? How are these used differently from the methods parameters with the same names?

The semantics of the move() method are counterintuitive, too.  What does a Person have anything to do with the movement of an elevator? Is the assumption that there's a 1-to-1 destination floor and Person? That is, your elevator simulator seems to only allow loading/unloading ONE person at a time, and only ONE person can get off at a given floor.
+Pie Number of slices to send: Send
Thank you Piet for looking things over. I really appreciate it. PersonList is an array of Persons that will be taking the elevator (I would have used an ArrayList instead but we were not supposed to). MAX_NUMBER is the maximum number of persons that will take the elevator.

There are two stacks because one stack is for those on the elevator and the other one is to hold those who have to temporarily get off to allow those who have reached their desired floor to get off permanently. The temp stack is then popped until those who temporaily got off can get back on.

The elevator moves up or down and then the elevator is unloaded. I left the unload() out because it appears to be working fine. It unloads anyone that needs to get off the elevator after it has moved up or down one floor.

The second parameter in move() is left over from a previous version of the method. It should not be there.

I am trying to go with this change to the move() method: (ePersonStack.getMaxExitFloor() > currentFloor). The elevator moves up or down now based on the maximum desired exit floor of the set of current passengers and compares that to the current floor. I do not understand but I cannot use j-- anymore to reset j as it creates an endless loop. But now a person is skipped if they do not meet the criteria for personList[j].flloorEntered == currentFloor and they do not get loaded.

I will try to work on a SSCCE but not quite sure how to narrow the code down into a small testable piece of code.
1
+Pie Number of slices to send: Send
It seems to me that a Stack is not the correct data structure to use for this problem. A stack is LIFO (last in, first out), an elevator is not.  The only limit to the number of people getting on at any given floor is the elevator's capacity.

Also, it seems that a direction instance variable is needed so that you can calculate whether the elevator should continue in the current direction or reverse and go the other way.  That is, if the elevator has just going up and stops on the 4th floor and all of the people currently in the elevator want to go to the 1st floor but someone just go on who wants to go to the 5th floor, what should the elevator do?  Should it continue to the 5th floor before reversing directions or should it reverse direction now, taking the last person to get on for a little detour downstairs so that the people who got on the elevator before him can get off.  What if two people get on at the 4th floor but one person wants to go to the 5th floor while the other one wants to go to the 1st floor? Should the elevator keep going up before it reverses direction?

From my experience with elevators, here are some rules that I observe they seem to follow:

1. If the elevator is going up, it will keep going up until it reaches the highest floor number that is pressed.
2. Conversely, if the elevator is going down, it will keep going down until it reaches the lowest floor number that is pressed.
3. If you press a floor number that would require the elevator to reverse directions, rules #1 or #2 take precedence.

It seems to me that the logical call to a move() method would be something like this:

In the nextStopFloor() method, you would check the current direction, the current floor, and the destination floors of all the People who are currently in the elevator to determine what floor the elevator needs to stop on next.
1
+Pie Number of slices to send: Send
how the elevator moves is up to Jaime, I do not want to prescribe anything. My biggest problem is, from the code I saw so far, is that it indeed seems like that the latest passenger entering the elevator, determines the direction (okay for me), but where do I see if there are more than one person stepping in, or where they get out, or that every floor has its own waiting crowd. Maybe Jaiime can explain the situation in plain language how the population is split over all the floors (if at all), as to orientate our ideas.
1
+Pie Number of slices to send: Send
 

Jaime Alnwick wrote:There are two stacks because one stack is for those on the elevator and the other one is to hold those who have to temporarily get off to allow those who have reached their desired floor to get off permanently. The temp stack is then popped until those who temporaily got off can get back on.


It's counterintuitive but it's a workable design, I suppose.  If it were me and I absolutely had to use Stacks for this, I would just use a local variable for the temporary Stack, then overwrite the instance variable. That is, something like this:
+Pie Number of slices to send: Send
Junilu,

Thank you very much. Sorry the names were not intuitive. I was just trying not to post unnecessary information and I think I have been staring at them for too long.

We actually have to stick with a LIFO style elevator. That is one of the program requirements since we have been studying stacks. The "e" stands for elevator and the "l" stands for lobby. the ePersonStack is a stack of Persons on the elevator. The lPersonStack is the stack of Persons who have temporarily gotten off the elevator to let those who have reached their desired floor off. They then have to get back on in their original order.

Thanks for the tips on elevators and how they would move. That was very helpful. I will try reworking the move method looking at it from that persepctive. I definitely have some things to work on. Thanks again for the tips.
1
+Pie Number of slices to send: Send
I'm not trying to prescribe anything; I'm just pointing out what I have observed about real-world elevator behavior and the incongruities with the code for the simulated elevator.

If OP can clarify exactly what rules govern the movement of the simulated elevator, that would certainly help keep us on track.
1
+Pie Number of slices to send: Send
 

Jaime Alnwick wrote:Sorry the names were not intuitive.


No need to apologize to me. If you really want to make it up to us, you'd rename those variables.

Seriously though, there is a direct correlation between good names and clean code.
1
+Pie Number of slices to send: Send
 

I wrote:
If it were me and I absolutely had to use Stacks for this, I would just use a local variable for the temporary Stack, then overwrite the instance variable.


There's a principle involved in doing this: Keep the scope of variables as small as possible. This keeps dependencies and interactions as limited as possible. Think about it, what other method needs the stack that holds the People that you're temporarily taking off the elevator? Only the unload() method uses it. So why make it accessible to anything else by declaring the temporary stack as an instance variable?  You only need it to perform the unload() operation so keep the temporary stack local to that method.
+Pie Number of slices to send: Send
Currently, I made that change I mentioned so that the elevator moves up if the passenger with the maximum exit floor is greater than the current floor. Otherwise it moves down. The max exit floor is continually reclaculated. This is working except for the missing passenger person who doesn't get loaded because they do not get evaluated.

More than one person can get in because the for loop cycles through the potential passengers in the load method. If there is no room (the elevator is full at capacity 5), they have to take the stairs.

I originally had it wrong but the direction should be dictated by the direction in which the elevator is already moving. If there is no one waiting it would be nice to be able to change directions though. If someone has the chance to get on, they are supposed to get on even if the elevator is going the opposite direction because they want to secure a spot.
1
+Pie Number of slices to send: Send
Here's a problem I see: your load() method calls the move() and unload() methods while it's iterating over the list of people who want to get on the elevator. Why?  Seems to me that this would be your overall controlling logic:
1
+Pie Number of slices to send: Send
 

Jaime Alnwick wrote:Currently, I made that change I mentioned so that the elevator moves up if the passenger with the maximum exit floor is greater than the current floor. Otherwise it moves down. The max exit floor is continually reclaculated.


Based solely on that description, it would seem to me that this elevator is a bit unfair. So if the elevator was going down, goes to the 3rd floor, then someone got on who wanted to go to the 5th floor, the elevator would go back up to the 5th floor first.  Imagine being on that elevator and wanting to go to the ground floor but people keep getting on at the middle floors who are going to a party on the top floor.
1
+Pie Number of slices to send: Send
Consider this declaration:

The declared type is an array of Person objects. The name says this is a personList.  Since List is also an interface in the standard Java Collections API, this creates a bit of signal interference in the reader's brain if they are familiar with java.util.List

Another thing, "list" is more of an implementation detail. Your names should be more about intent and purpose rather than implementation.

Now, consider what renaming it to this would do to the readability of your code:

That name doesn't tell so much about the implementation; rather, it tells what is being represented, a group of people who are waiting to get on the elevator.
1
+Pie Number of slices to send: Send
 

Junilu Lacar wrote:

Jaime Alnwick wrote:Currently, I made that change I mentioned so that the elevator moves up if the passenger with the maximum exit floor is greater than the current floor. Otherwise it moves down. The max exit floor is continually reclaculated.


Based solely on that description, it would seem to me that this elevator is a bit unfair. So if the elevator was going down, goes to the 3rd floor, then someone got on who wanted to go to the 5th floor, the elevator would go back up to the 5th floor first.  Imagine being on that elevator and wanting to go to the ground floor but people keep getting on at the middle floors who are going to a party on the top floor.


In the original code, the move was only one floor up or down, per passenger, so direction could change at any floor. That's why I mentioned a Brownsian motion. But loading and unloading are two processes, and determining the direction is another one. Given some elevator population, you can think of all kinds of algo''s to let that elevator move. Why is the LIFO, from elevator to eSack, important? Those temporarily leaving the elevator to let other people out, get back in the same order, so in effect all that happens is that those who arrived at their floor, get out. Well, 'nough said, over to the others.
1
+Pie Number of slices to send: Send
Piet, unless I'm misunderstanding you, your reasoning seems inconsistent. First you say that LIFO is important to preserve the order in which you temporarily "unload" people from the elevator. Then you say that the net effect is that people who want to get off are removed. How is the order that people get on or off the elevator even relevant? The only important thing to know is whether a person is getting/staying on or off; it doesn't matter what order people get on at any particular floor. It doesn't matter what order they get off either, as long as they get off at their desired floor.
1
+Pie Number of slices to send: Send
That is, if person A, B, C, D, E are on the elevator and they reach the 3rd floor where only C wants to get off, it doesn't matter which order A,B,D, and E are moved off and on the elevator again so that C can be unloaded. Conversely, if A and B both want to get off at the same floor, it doesn't matter which one you take off first as long as both of them are off before moving the elevator to the next destination floor.
1
+Pie Number of slices to send: Send
Junilu and Piet, Just wanted to say a final thank you for all your help on the elevator problem. The discussion really helped me move forward when I was really stuck. I actually got a good score on the assignment. There were still a couple things I wish I would have done differently but at least I will have a better idea how to handle a similar problem if it comes up in the future. Well, back to working on my current assignment...
+Pie Number of slices to send: Send
hi Jaime,

well I'm glad you found satisfaction in your solution! It certainly boggled my mind at first.

Junilu wrote:Piet, unless I'm misunderstanding you, your reasoning seems inconsistent. First you say that LIFO is important to preserve the order in which you temporarily "unload" people from the elevator. Then you say that the net effect is that people who want to get off are removed. How is the order that people get on or off the elevator even relevant? The only important thing to know is whether a person is getting/staying on or off; it doesn't matter what order people get on at any particular floor. It doesn't matter what order they get off either, as long as they get off at their desired floor.


Yes, perhaps. I struggled with the model I had in mind. I was comparing it to a cargo ship, laying in a harbour, given some route to other harbours, and then the loading of the freight would be such that the cargo for the first harbour to be visisted would have to be loaded last, LIFO, for efficiency reasons. But then a route to harbours is given, which is not according to what I thought was being asked.
So, I struggled with the model. However, the discussion was so much between you and Jaime that I gave up on this topic.
Roses are red, violets are blue. Some poems rhyme and some don't. And some poems are a tiny ad.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 8405 times.
Similar Threads
Elevator Final Result
Could I run some ideas by you?
Elevator Errors
Elevator problem: How to add a condition to move one elevator at a time
HAS-A relationship?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 09:29:46.