• Post Reply Bookmark Topic Watch Topic
  • New Topic

Elevator Simulator  RSS feed

 
Jaime Alnwick
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


 
Jaime Alnwick
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Piet Souris
Master Rancher
Posts: 2044
75
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jaime Alnwick
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Piet Souris
Master Rancher
Posts: 2044
75
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
Jaime Alnwick
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jaime Alnwick
Greenhorn
Posts: 16
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Piet Souris
Master Rancher
Posts: 2044
75
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jaime Alnwick
Greenhorn
Posts: 16
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Piet Souris
Master Rancher
Posts: 2044
75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!