Group 1:
Yang: The only thing we did was to top sort the planes like a tree. The planes are a leaf and their parent is the time of the flight it is dependent on. We are using this to order the plane’s takeoff.
Vishwa <absent>
Hari
Group 2:
Harjot <absent>
Tieram: Given that we cannot go through and simulate everything, the chain of dependencies are a good heuristic
Sam: The main thing that we still need to fix is preferring planes that have other dependencies. We take everything off as soon as possible. When a plane gets into a hub with a lot of planes we do not prioritize the planes that have dependencies. The flight with the longest chain of dependencies.
Group 3
Marcus
Hao
Franklin
Group 4
Tanay
Yigit:
Tim: We assign a total time to every flight which is the cumulative sum of that flight’s departure time, the distance of the flight, and the longest total time of all its dependency. Build up a stock of dependencies. We prioritize those by sending them first to the flight route generator. It is hard to look at the board and seeing how to optimize the strategy like you could with the standard game.
Group 5
Tanveer <absent>
Lauren: We continued to look at different priority algorithms. We sort off of the departure plane and flight path with dependencies.
Jinesh: the one plane is making a semi circle because we decided that it was better to take off then to delay.
Group 6
Di <excused absence>
Patrick: we make a hash set of when the planes arrive. If the plane has no dependencies, then we take them off list. We launch the plane that will arrive later.
Monday, December 9, 2013
Thursday, December 5, 2013
Airplanes 12/03
Group 1:
Yang: We are changed our method to look at both the delay and different angles. We can now let the plane that is arriving latest to take off first. The hard problem will be if you set all the planes at time 0, since it would be hard to prioritize. This change of strategy improves almost all the boards, only Test 10 round flights 10 planes each did not do better. The reason is, if you assign for delay then you will create a small flow and block part of the board. We are focusing on minimizing the delay only since it is hard to measure throughput. For the dependent planes, we made the plane not take off until all the planes it is dependent on have landed. We are thinking of using the entire flights with the connecting flights counted.
Vishwa: The plane flight path will effect other planes in tight pack. The first path curves, so the next one curves and so on. Complications only really happen when there is a lot of planes on the board and a lot of collisions.
Hari
Group 2:
Harjot: We made a change to make the plane take off even if there will be a crash and depend on A* to avoid the
Tieram: Our strategy does not allow planes to take off before they are able to.
Sam: Dependancies mostly worked out of the box, we just had to remove the sorting. We were doing a simple sorting of distance. Moving forward we want to create a better sorting algorithm. We are now sorting by distance and want to have a series of candidates, with the flights with no dependancies take off first.
Group 3
Marcus: We are implementing a graph algorithm to change the planning queue for launching planes. We are first looking at departure time, then the dependent flight’s take departure time. This should still preserve the longest path straight, even with connections.
Hao
Franklin: This new development in the simulation makes it easier, since the dependencies makes it easier to prioritize the flights.
Group 4
Tanay:
Yigit:
Tim: We sort the planes by the total path of the plan’s distance and their dependent plane’s distance. We spent the first part of the break, refactoring and cleaning up code. We then started looking at the dependance problem. We fit our code to the new situation, delaying the planes until their dependent plane has landed. We changed the sorting method of plane deployment for the largest total flight (looking at the multiple flight as one long flight). We are having a problem with using both non-deterministic deployment and deterministic deployment.
Group 5
Tanveer
Lauren: did not make any changed to the original player. We tried out a number of different orderings and recorded the results. Non of them really stand out as the best orderings.
Jinesh <Absent>
Group 6
Di: modified the last solution a bit to fix the gap between the planes in the tight pack board. For the dependancies, we are currently debugging. We are prioritizing the plane that has the most dependancies and the longest distance.
Patrick
Yang: We are changed our method to look at both the delay and different angles. We can now let the plane that is arriving latest to take off first. The hard problem will be if you set all the planes at time 0, since it would be hard to prioritize. This change of strategy improves almost all the boards, only Test 10 round flights 10 planes each did not do better. The reason is, if you assign for delay then you will create a small flow and block part of the board. We are focusing on minimizing the delay only since it is hard to measure throughput. For the dependent planes, we made the plane not take off until all the planes it is dependent on have landed. We are thinking of using the entire flights with the connecting flights counted.
Vishwa: The plane flight path will effect other planes in tight pack. The first path curves, so the next one curves and so on. Complications only really happen when there is a lot of planes on the board and a lot of collisions.
Hari
Group 2:
Harjot: We made a change to make the plane take off even if there will be a crash and depend on A* to avoid the
Tieram: Our strategy does not allow planes to take off before they are able to.
Sam: Dependancies mostly worked out of the box, we just had to remove the sorting. We were doing a simple sorting of distance. Moving forward we want to create a better sorting algorithm. We are now sorting by distance and want to have a series of candidates, with the flights with no dependancies take off first.
Group 3
Marcus: We are implementing a graph algorithm to change the planning queue for launching planes. We are first looking at departure time, then the dependent flight’s take departure time. This should still preserve the longest path straight, even with connections.
Hao
Franklin: This new development in the simulation makes it easier, since the dependencies makes it easier to prioritize the flights.
Group 4
Tanay:
Yigit:
Tim: We sort the planes by the total path of the plan’s distance and their dependent plane’s distance. We spent the first part of the break, refactoring and cleaning up code. We then started looking at the dependance problem. We fit our code to the new situation, delaying the planes until their dependent plane has landed. We changed the sorting method of plane deployment for the largest total flight (looking at the multiple flight as one long flight). We are having a problem with using both non-deterministic deployment and deterministic deployment.
Group 5
Tanveer
Lauren: did not make any changed to the original player. We tried out a number of different orderings and recorded the results. Non of them really stand out as the best orderings.
Jinesh <Absent>
Group 6
Di: modified the last solution a bit to fix the gap between the planes in the tight pack board. For the dependancies, we are currently debugging. We are prioritizing the plane that has the most dependancies and the longest distance.
Patrick
Tuesday, December 3, 2013
Airplane 11/26
Group 1:
Yang:
Vishwa: Doing data analysis with excel. Trying to figure out with player better. The only board that has significant differences is in the stream
Hari:
Group 2:
Harjot: Added flow detection, so we are doing much better at those boards. Create a white box to show the obstacles during the flight. Once a flow is detected, those planes do not use A*, they just follow the flow path. We set up flow, buy seeing how many planes are in the flows and how long it is.
Tieram: <Excused>
Sam: We detect where the planes will collide and will create an obstacle at the location. To detect flows by how many planes are in the same distance. We give prescience to the longest flow and create waypoints around it.
Group 3
Marcus:
Hao: We have made improvements for the delay and detour. If we cannot find an angle that avoids the crash in 10 rounds, then just delay.
Franklin: We had the issue where our simulator was not working. We have fixed this. If there is a head on collision, then find an arch path to run. Our player runs a lot of simulators so it takes a while. We are looking into detecting flows, also looking at waypoints to get around the flows. We don’t detect head on collisions very well.
Group 4
Tanay: Were doing very poorly on the flows and on tight pack. We do poorly on these because we don’t look forward enough, we only look 30 steps ahead. We are looking at arcs and going around flows using having waypoints
Yigit:
Tim: <Absent>
Group 5
Tanveer: We have better collisions detection, but otherwise we have the same strategy. We have three movement patterns, a straight line, a curved takeoff and A*. We are not doing any calculation on whether it is better to take off and move around or to delay.
Lauren: We were looking into moving planes into safe zones, but we found that there are a lot of calculations and real time analysis. We decided that it was not worth continuing since it would only be useful on certain boards.
Jinesh:
Group 6
Di: Trying to schedule the plane to go directly to the destination, then delay by one. Prioritizing the plane with the longest flight. We will try to detour the planes if we can. Find that most of the planes are delayed. The detour will make the plane take off at another angle and then turn back to its destination.
Patrick <Excused>
Yang:
Vishwa: Doing data analysis with excel. Trying to figure out with player better. The only board that has significant differences is in the stream
Hari:
Group 2:
Harjot: Added flow detection, so we are doing much better at those boards. Create a white box to show the obstacles during the flight. Once a flow is detected, those planes do not use A*, they just follow the flow path. We set up flow, buy seeing how many planes are in the flows and how long it is.
Tieram: <Excused>
Sam: We detect where the planes will collide and will create an obstacle at the location. To detect flows by how many planes are in the same distance. We give prescience to the longest flow and create waypoints around it.
Group 3
Marcus:
Hao: We have made improvements for the delay and detour. If we cannot find an angle that avoids the crash in 10 rounds, then just delay.
Franklin: We had the issue where our simulator was not working. We have fixed this. If there is a head on collision, then find an arch path to run. Our player runs a lot of simulators so it takes a while. We are looking into detecting flows, also looking at waypoints to get around the flows. We don’t detect head on collisions very well.
Group 4
Tanay: Were doing very poorly on the flows and on tight pack. We do poorly on these because we don’t look forward enough, we only look 30 steps ahead. We are looking at arcs and going around flows using having waypoints
Yigit:
Tim: <Absent>
Group 5
Tanveer: We have better collisions detection, but otherwise we have the same strategy. We have three movement patterns, a straight line, a curved takeoff and A*. We are not doing any calculation on whether it is better to take off and move around or to delay.
Lauren: We were looking into moving planes into safe zones, but we found that there are a lot of calculations and real time analysis. We decided that it was not worth continuing since it would only be useful on certain boards.
Jinesh:
Group 6
Di: Trying to schedule the plane to go directly to the destination, then delay by one. Prioritizing the plane with the longest flight. We will try to detour the planes if we can. Find that most of the planes are delayed. The detour will make the plane take off at another angle and then turn back to its destination.
Patrick <Excused>
Thursday, November 21, 2013
Airplane 11/21
Group 1:
Yang: Combined the delay and the angle search together. There is no way to get the optimal in a reasonable amount of time, so the code greedily assigns the takeoff and angle. Will look into detecting the impacts on other flights.
Vishwa:
Hari: <excused absence>
Group 2:
Harjot
Tieram: The prioritization influences the order the paths are resulted. So the most problematic flight are resolved first. We have found that this is too simple of a metric and does not work very well.
Sam: worked on identifying and dealing with flows. Did a very similar strategy to group 5, made a wall at the flow and used A* to get around it. The other thing we worked on was prioritizing planes. We first looked at departure time and distance, also at number of intersections (most problematic flights). There was not one strategy that was better then any other. Once the planes are in the air, they don’t change their path.
Group 3
Marcus: Doing a while loop through the planes. Will first see if the plane can get delayed. IF there is a head on collision, we go through the angles to find a good angle for the plane. This is where the infinite loop is.
Hao
Franklin: last week our algorithm was not doing well with many planes. This is because we got stuck in an infinite loop.
Group 4
Tanay: on flow based boards, we need to have the planes go on more of an angle then 10 degrees. Looking at algorithms to find flows.
Yigit <absent>
Tim: We have an array that has all the plane’s location at a round. If we see that there are a lot of planes at the same place in the array, we know that it is a flow.
Group 5
Tanveer: the collision detection is a bit batter then before, it is more general. If there is a crash very near the airport, then the plane departing from the airport will take off on the opposite side. We are not looking at better angles to save on computational time.
Lauren: working on implementing the safety zones. When there are flows on the board, and we are using A*, the A* fails because there is no space to move. We are working on making safe zones to move the planes to if A* fails. We are also working on better collision detection. Previously we were only looking at head on collisions, we are looking at more collisions.
Jinesh
Group 6
Di
Patrick<excused absence>
Future Airplane suggestions
Connecting flights (one to many)
Weather patterns
Change speed
Maximum distance a plane could fly
Add a Z option, so three can be over each other, but 4 is a problem.
No fly zone or Bermuda triangle that randomly changes berring
Yang: Combined the delay and the angle search together. There is no way to get the optimal in a reasonable amount of time, so the code greedily assigns the takeoff and angle. Will look into detecting the impacts on other flights.
Vishwa:
Hari: <excused absence>
Group 2:
Harjot
Tieram: The prioritization influences the order the paths are resulted. So the most problematic flight are resolved first. We have found that this is too simple of a metric and does not work very well.
Sam: worked on identifying and dealing with flows. Did a very similar strategy to group 5, made a wall at the flow and used A* to get around it. The other thing we worked on was prioritizing planes. We first looked at departure time and distance, also at number of intersections (most problematic flights). There was not one strategy that was better then any other. Once the planes are in the air, they don’t change their path.
Group 3
Marcus: Doing a while loop through the planes. Will first see if the plane can get delayed. IF there is a head on collision, we go through the angles to find a good angle for the plane. This is where the infinite loop is.
Hao
Franklin: last week our algorithm was not doing well with many planes. This is because we got stuck in an infinite loop.
Group 4
Tanay: on flow based boards, we need to have the planes go on more of an angle then 10 degrees. Looking at algorithms to find flows.
Yigit <absent>
Tim: We have an array that has all the plane’s location at a round. If we see that there are a lot of planes at the same place in the array, we know that it is a flow.
Group 5
Tanveer: the collision detection is a bit batter then before, it is more general. If there is a crash very near the airport, then the plane departing from the airport will take off on the opposite side. We are not looking at better angles to save on computational time.
Lauren: working on implementing the safety zones. When there are flows on the board, and we are using A*, the A* fails because there is no space to move. We are working on making safe zones to move the planes to if A* fails. We are also working on better collision detection. Previously we were only looking at head on collisions, we are looking at more collisions.
Jinesh
Group 6
Di
Patrick<excused absence>
Future Airplane suggestions
Connecting flights (one to many)
Weather patterns
Change speed
Maximum distance a plane could fly
Add a Z option, so three can be over each other, but 4 is a problem.
No fly zone or Bermuda triangle that randomly changes berring
Tuesday, November 19, 2013
Airplane 11/14
Group 1:
Yang: Changing plans’ path to go in a curve if there is a crash. There is a trade off between each plane delaying or moving in a curved path. The curved path will take that plane away from the more populated areas. There is no guaranteed that you will get the straight path if you delay.
Vishwa: Tried to optimize performance. Taking into consideration multiple items to prioritize planes. Using the simulation inside the simulation to test if the curve will avoid the crash. On a crowded board it is better to make larger curves to get out of the way. Our approach will not work in a multi-player world, but it should work well in a static world. We only use the angle selection in the beginning before the plane has taken off, nothing gets changed in flight. The flights are evaluated in a certain order, once the plane’s angle is set, all other planes adjust their flight to it. We are not seeing any planes that are taking larger angles. Can optimize the flights to delay more or to have a longer angle. The large angle could lessen the delay, but the plane will be in the air more.
Hari: Look at distance and departure time, to sort planes to change the flight path of.
Group 2:
Harjot: Last time we showed the strategy where the planes will ___. We now look at this as having the obstacle that are moving. Let the plane go in a straight path. Then draw a wall in front of the plane and then uses A*. This is similar to the locking system. After the avoidance we can optimize the delay vs avoid. Does not have something to show yet. Will be plugging in the A* implementation from the mosquito. Will be adding heuristics to avoid having planes moving way out of the way to avoid a crash
Tieram:
Sam:
Group 3
Marcus: We are doing delay first then arcs, which would be better, arch or delay first. Think the end result will be the same.
Hao: if there is a head on crash, then we want the two planes to avoid each other. This has three phases, move to the destination, move away from the other plane, and then move back to the destination. This uses fixed paths. When the simulator detects a crash, find area of the crash and the crash points. When the plane gets to the crash point, move around the crash area and back to the destination. The planes will continue turning after the crash site to get back to its original path.
Franklin: strategy was to only delay. Which works well except for head on collisions.
Group 4
Tanay: Implemented timed delay. If planes are moving towards each other then the implementation is serialized
Yigit:
Tim: working on making a wrinkle in time.
Group 5
Tanveer: Think of the crash point as a junction, and have a time block on that junction. If the angle of crash is greater then 5 degrees, then use delay, otherwise redirect the plane. Will redirect whichever plane is first in the list. Using simulation inside the simulator to check the redirection. Lauren: Changed the strategy, used to have zones around the airport. Decided that the only disadvantage of the delay strategy was the co-linear path. Currently only using delay unless the planes are co-linear.
Jinesh: If the redirection angle is too large then use the delay.
Group 6
Di: The planes start moving at an angle and once it sees its ok to go to the destination, it moves directly there. Thinks it is better to take off and avoid and then to delay.
Patrick: Had trouble with seeing how the plane has gone during A*. Is currently implementing abstractions to see where the plans are at any given time. Flights that departs first and have a long path will be prioritized. Will use Di’s algorithm to move the planes away from the crashes.
Yang: Changing plans’ path to go in a curve if there is a crash. There is a trade off between each plane delaying or moving in a curved path. The curved path will take that plane away from the more populated areas. There is no guaranteed that you will get the straight path if you delay.
Vishwa: Tried to optimize performance. Taking into consideration multiple items to prioritize planes. Using the simulation inside the simulation to test if the curve will avoid the crash. On a crowded board it is better to make larger curves to get out of the way. Our approach will not work in a multi-player world, but it should work well in a static world. We only use the angle selection in the beginning before the plane has taken off, nothing gets changed in flight. The flights are evaluated in a certain order, once the plane’s angle is set, all other planes adjust their flight to it. We are not seeing any planes that are taking larger angles. Can optimize the flights to delay more or to have a longer angle. The large angle could lessen the delay, but the plane will be in the air more.
Hari: Look at distance and departure time, to sort planes to change the flight path of.
Group 2:
Harjot: Last time we showed the strategy where the planes will ___. We now look at this as having the obstacle that are moving. Let the plane go in a straight path. Then draw a wall in front of the plane and then uses A*. This is similar to the locking system. After the avoidance we can optimize the delay vs avoid. Does not have something to show yet. Will be plugging in the A* implementation from the mosquito. Will be adding heuristics to avoid having planes moving way out of the way to avoid a crash
Tieram:
Sam:
Group 3
Marcus: We are doing delay first then arcs, which would be better, arch or delay first. Think the end result will be the same.
Hao: if there is a head on crash, then we want the two planes to avoid each other. This has three phases, move to the destination, move away from the other plane, and then move back to the destination. This uses fixed paths. When the simulator detects a crash, find area of the crash and the crash points. When the plane gets to the crash point, move around the crash area and back to the destination. The planes will continue turning after the crash site to get back to its original path.
Franklin: strategy was to only delay. Which works well except for head on collisions.
Group 4
Tanay: Implemented timed delay. If planes are moving towards each other then the implementation is serialized
Yigit:
Tim: working on making a wrinkle in time.
Group 5
Tanveer: Think of the crash point as a junction, and have a time block on that junction. If the angle of crash is greater then 5 degrees, then use delay, otherwise redirect the plane. Will redirect whichever plane is first in the list. Using simulation inside the simulator to check the redirection. Lauren: Changed the strategy, used to have zones around the airport. Decided that the only disadvantage of the delay strategy was the co-linear path. Currently only using delay unless the planes are co-linear.
Jinesh: If the redirection angle is too large then use the delay.
Group 6
Di: The planes start moving at an angle and once it sees its ok to go to the destination, it moves directly there. Thinks it is better to take off and avoid and then to delay.
Patrick: Had trouble with seeing how the plane has gone during A*. Is currently implementing abstractions to see where the plans are at any given time. Flights that departs first and have a long path will be prioritized. Will use Di’s algorithm to move the planes away from the crashes.
Airplane 11/19
Group 1:
Yang: Trying to assign a curve to each plane in a crash. Will prioritize the flight path and the departure time. This does not always work well since the shorter flights might have to curve more. Previously only looks at the planes about to take off. Now look at each flights based on length no matter the take off time. Tries to get the plane to take off first at an angle before it delays.
Vishwa:
Hari:
Group 2:
Harjot : last time talked about avoidance using A*. Ended up using the simulation. The delay is automatically evaluated since if there is no A* path, then the plane does not take off. When the simulator detects a crash, we create an obstacle box at that point which A* uses to move around. The flights are non deterministic because A* implementation is not deterministic. the bottlenecks are usually at the airports, taking off or landing.
Tieram: There are a lot of cases where taking off another direction and then moving is better then waiting
Sam:
Work on next: prioritization, creating a continuous flow in flow like problems.
Group 3
Marcus: Run the simulation within the simulation that the first two are calculated and the rest are seralized, then calculate the first three then the rest are serialized. We are currently prioritizing the departure time, might have better results prioritizing the arrival time. Not combining delay and arc, either delay plane only or arc only.
Hao:
Franklin: Having runtime issue with more then 15 flights. Still have strategy with delay, if the two planes are heading towards each other, then arc around the plane. If the plane delayed by more then 10, then find an arc that works. This does not actually make much of a difference. Delay first, then after 10 rounds, try and find an angle, if no angle can be found, then delay again.
Group 4
Tanay: If the flights are heading straight into each other, if two flights collide more then 15 times, then the two flights are on a problematic collision. In that case, we will put the two flights on the path and then look 5 steps ahead and greedily move one out of the path, pick the angle that works and gets you towards the destination.
Yigit:
Tim: look at how real air traffic control works. They look at time in air, so we are looking at power. We are preferring straight lines. We sort the straight lines and launch the longest path, and check against the next longest straight line. Will delay the shorter flight. Each plane if given a score of distance and take off time to priority
Group 5
Tanveer: Using the simulation, the primary strategy is the delay, then if there is a head on collision, use simple maths to find the path to narrowly miss it. . Also have the idea of flows, will keep . If there are a number of flights in the air, then seeing the flights as a wall and using A*. Also will change the take off angle if the collision is too close to the airport. To see if there is a flow, keep track of all the flight paths, and if there are more then 5 planes on the same path, then it is a flow.
Lauren:
Jinesh:Use A* to get around the flows on the board.
Group 6
Di:
Patrick: The vast majority of flights are non-conflicting. The trying to implement code to see which is better, delay or curve. Is still looking into using A* and how it might integrate with the other approach.
Yang: Trying to assign a curve to each plane in a crash. Will prioritize the flight path and the departure time. This does not always work well since the shorter flights might have to curve more. Previously only looks at the planes about to take off. Now look at each flights based on length no matter the take off time. Tries to get the plane to take off first at an angle before it delays.
Vishwa:
Hari:
Group 2:
Harjot : last time talked about avoidance using A*. Ended up using the simulation. The delay is automatically evaluated since if there is no A* path, then the plane does not take off. When the simulator detects a crash, we create an obstacle box at that point which A* uses to move around. The flights are non deterministic because A* implementation is not deterministic. the bottlenecks are usually at the airports, taking off or landing.
Tieram: There are a lot of cases where taking off another direction and then moving is better then waiting
Sam:
Work on next: prioritization, creating a continuous flow in flow like problems.
Group 3
Marcus: Run the simulation within the simulation that the first two are calculated and the rest are seralized, then calculate the first three then the rest are serialized. We are currently prioritizing the departure time, might have better results prioritizing the arrival time. Not combining delay and arc, either delay plane only or arc only.
Hao:
Franklin: Having runtime issue with more then 15 flights. Still have strategy with delay, if the two planes are heading towards each other, then arc around the plane. If the plane delayed by more then 10, then find an arc that works. This does not actually make much of a difference. Delay first, then after 10 rounds, try and find an angle, if no angle can be found, then delay again.
Group 4
Tanay: If the flights are heading straight into each other, if two flights collide more then 15 times, then the two flights are on a problematic collision. In that case, we will put the two flights on the path and then look 5 steps ahead and greedily move one out of the path, pick the angle that works and gets you towards the destination.
Yigit:
Tim: look at how real air traffic control works. They look at time in air, so we are looking at power. We are preferring straight lines. We sort the straight lines and launch the longest path, and check against the next longest straight line. Will delay the shorter flight. Each plane if given a score of distance and take off time to priority
Group 5
Tanveer: Using the simulation, the primary strategy is the delay, then if there is a head on collision, use simple maths to find the path to narrowly miss it. . Also have the idea of flows, will keep . If there are a number of flights in the air, then seeing the flights as a wall and using A*. Also will change the take off angle if the collision is too close to the airport. To see if there is a flow, keep track of all the flight paths, and if there are more then 5 planes on the same path, then it is a flow.
Lauren:
Jinesh:Use A* to get around the flows on the board.
Group 6
Di:
Patrick: The vast majority of flights are non-conflicting. The trying to implement code to see which is better, delay or curve. Is still looking into using A* and how it might integrate with the other approach.
Thursday, November 14, 2013
Airplanes 11/12
Group 1:
Yang: You have three options to get from A to B, go straight from A to B, or go on a curve from A to B with a certain radius, or go from A to midpoint c and then back to B. We are using the curve option. The plane starts at a certain angle and checks if there are any crashes. Assigning the path at the time of flight take off.
Vishwa: Observations: We have observed that the lower bound of the best time is as long as the longest flight. Strategy: We will iterate through the list of plane, for each plane we try to find a curved flight path where the curve is a random angle where there are no crashes. We are not currently dynamically moving any plane. We found the plane with the longest distance and that plane will not be changed. Tried to create a priority queue, but had trouble with sorting the bearings. Optimized the player to choose an avoidance angle between -30 and 30.
Hari: Also needed to take into account the departure round.
Group 2:
Harjot:
Tieram: Ran into a problem “pinning” flights that the planes would go parallel to each other. Had two strategies, delay the planes and a dynamic collision avoidance. For the dynamic avoidance strategy, when ever the plans have are too close to each other, they both change their angle away from the on coming plane. The Delay strategy uses math to calculate the delay. If the two planes are heading directly into each other then the avoidance strategy forces the planes to keep turning until they are moving directly away from each other.
Sam:
Group 3
Marcus: Our delay strategy does not work for head on collisions. The departure time delays the flight until the collision has past. The delay gets the closest to the optimal steps. Then look at the planes that have the greatest delay to curve their flight plan.
Hao:
Franklin: Also thinking about using “locks”. We are going to divide the board into 4 x 4 sections, the planes will not take off unless they have all the “locks” to get to their destination. Going to work on figuring out which strategy, delay or avoid is the best to use with the planes.
Group 4
Tanay
Yigit
Tim: also recognized that the lower bound of the best case was the straight line path of the longest flight. Instead of making curves, we delayed the flight. This minimizes the power. We would find the longest flight and “pined” the flight. Does not take into account the departure round. This is also deterministic.
Group 5
Tanveer: Current strategy is to make zones on the boards depending on the airports. If there are multiple flights going to the the same airport, the other planes queue up around the zone. These paths are determines as the planes take off. The planes will not know if they can land until they try to land. We will be trying to optimize the zones to include multiple airports.
Lauren: Thinking about both delay and collision avoidance. Looking at space delay strategy. Worked on finding collision points and then avoiding them. Right now we only look at cashes at the air port.
Jinesh: We are tinkering with the airport zone area.
Group 6
Di: Looking at both delaying and avoidance. Worked on code to make one plane detour and one plane continue straight. No intelligent decision on how to choose which plane gets rerouted and which one goes straight. Always turn the plane to the right.
Patrick: Decided to work on a time dependent A* algorithm. Run the first plane on an A* algorithm. Each node with a plane on it will be weighted really highly. This does not allow a straight line path. This takes care of the situation where two planes are flying towards each other. But this does not take into account the situations where the two flights are departing or arriving at the same destination.
Yang: You have three options to get from A to B, go straight from A to B, or go on a curve from A to B with a certain radius, or go from A to midpoint c and then back to B. We are using the curve option. The plane starts at a certain angle and checks if there are any crashes. Assigning the path at the time of flight take off.
Vishwa: Observations: We have observed that the lower bound of the best time is as long as the longest flight. Strategy: We will iterate through the list of plane, for each plane we try to find a curved flight path where the curve is a random angle where there are no crashes. We are not currently dynamically moving any plane. We found the plane with the longest distance and that plane will not be changed. Tried to create a priority queue, but had trouble with sorting the bearings. Optimized the player to choose an avoidance angle between -30 and 30.
Hari: Also needed to take into account the departure round.
Group 2:
Harjot:
Tieram: Ran into a problem “pinning” flights that the planes would go parallel to each other. Had two strategies, delay the planes and a dynamic collision avoidance. For the dynamic avoidance strategy, when ever the plans have are too close to each other, they both change their angle away from the on coming plane. The Delay strategy uses math to calculate the delay. If the two planes are heading directly into each other then the avoidance strategy forces the planes to keep turning until they are moving directly away from each other.
Sam:
Group 3
Marcus: Our delay strategy does not work for head on collisions. The departure time delays the flight until the collision has past. The delay gets the closest to the optimal steps. Then look at the planes that have the greatest delay to curve their flight plan.
Hao:
Franklin: Also thinking about using “locks”. We are going to divide the board into 4 x 4 sections, the planes will not take off unless they have all the “locks” to get to their destination. Going to work on figuring out which strategy, delay or avoid is the best to use with the planes.
Group 4
Tanay
Yigit
Tim: also recognized that the lower bound of the best case was the straight line path of the longest flight. Instead of making curves, we delayed the flight. This minimizes the power. We would find the longest flight and “pined” the flight. Does not take into account the departure round. This is also deterministic.
Group 5
Tanveer: Current strategy is to make zones on the boards depending on the airports. If there are multiple flights going to the the same airport, the other planes queue up around the zone. These paths are determines as the planes take off. The planes will not know if they can land until they try to land. We will be trying to optimize the zones to include multiple airports.
Lauren: Thinking about both delay and collision avoidance. Looking at space delay strategy. Worked on finding collision points and then avoiding them. Right now we only look at cashes at the air port.
Jinesh: We are tinkering with the airport zone area.
Group 6
Di: Looking at both delaying and avoidance. Worked on code to make one plane detour and one plane continue straight. No intelligent decision on how to choose which plane gets rerouted and which one goes straight. Always turn the plane to the right.
Patrick: Decided to work on a time dependent A* algorithm. Run the first plane on an A* algorithm. Each node with a plane on it will be weighted really highly. This does not allow a straight line path. This takes care of the situation where two planes are flying towards each other. But this does not take into account the situations where the two flights are departing or arriving at the same destination.
Tuesday, October 29, 2013
Mosquito 10/24
Group 1:
Tim: The waypoints are pruned if they are unneeded, if we have uninteresting sections, our pruning function will combine it. We are also looking at the section size. If the size is too big, just going into the section is not enough. If it is too big, now have the lights do a loop around the section. If the number of lights exceed the lights randomly, if not, place them on the sections based on distance from collector. No current code to check if going to the section if beneficial (if there are no mosquitos). On small holes: Need to think about what the purpose is going through the hole, getting to mosquitos? or bringing mosquitos back? On placement of collector: If the lights arrive at the collector a lot before other lights, maybe the collector is not optimally.
Franklin: Have waypoints that are spaced out for the light to got to. The lights will go from the outside and then converge on the collector. Each of the lights move along their waypoints. The collector moves around based on the waypoints. The collector will be in the middle of the graph of the sections. Vishwa is working on the greedy behavior, if a light is already in a section, do not send another light there.
Vishwa <excused absence>
Group 2:
Jinesh:
Tieram: On Approach for small holes: we are ignoring it and also having problems with it. On sweeping: we are having the collector in the corner and have all the lights move towards the collector. Was concerned about the graphs doubling back on itself. Now, generating waypoints around edges, boxing around it to avoid loosing mosquitos. Second idea, how to handle areas in between. Are currently putting waypoints in between boxed in spaces from wall. Are only pruning nodes in wide open spaces, not around obstacles. Need to prune nodes at a corner. Thinking of pruning the waypoints around walls, or disconnect graph and use A* to get around them. Also having problems with small openings. Right now, putting nodes on each side and “hope for the best”. Thinking of adding a weight to make the lights go slower. Thinking of having a very sparse graph, where we will not get all mosquitos on the first path, or have a very comprehensive graph, and not go out. Our pruning strategy is not thinking about how big the light is. Need to adjust the nodes for line of sight from the light.
Di:
Group 3
Harjot: Have not done a lot of big improvements. Added preemptive stopping around the corners. The lights wait at the waypoints. The lights do not go to the targets that other lights are going to. The light are not placed very optimally, same code from the first week, Dividing the board into horizontal regions and places the lights in each section. The collector is placed on a modified minimum spanning tree using A*.
Tanveer: Satan takes a while to load since it is trying to find the best position for the collector based on the A* of all the walls. On Satan’s beard: When the mosquitos are too near the obstacles, the destination is the waypoint and not the mosquito itself
Hao:
Group 4
Sam: Collector is at the middle. It always is. If there is a wall, the program will try and place it as close to the middle as possible. The lights are placed on the corners. The lights are assigned to the sections they are assigned in the beginning, once done, it will go to the closest section. Had trouble getting around the walls, created a buffer and waiting. Now, the lights will pause when moving to get all the mosquitos to come. Problem with implementation is that there are too many sections. Will now, check if there are mosquitos within 5 from light. If not, then the section is marked as finished/claimed, if not, the light will go it it. Lights will abort early (stop sweeping) if it does not need to sweep section. The sweeping motion is predetermined based on the shape of the section. Might have been better if sweep was based on the locations of the mosquitos. Will have a hunter light to go out and get mosquitos that have been missed. The simulator is slow because of the buffer around the walls causing A* to be slow. The sweeping algorithm will start from the left and go down.
Patrick: The lights will pause after 30 movements, for about 5 rounds. This can be tweaked.
Hari: The lights only visit the collector once, after they have swept the sections to avoid duplicate work. The lights would get stuck in the sections because the sweeper was not handling very small sections well. Going forward, adjust the position of the collector.
Group 5
Marcus: Attempted to find the best way to get to through the board through minimum spanning tree. but the graph has too many leaves and is not as good as what we had before. Going to tweak the way to calculate the way to get the path between the nodes. Going to discard the graph, while keeping the the nodes.
Tanay: The collector is placed,
Lauren: Experimented with new approaches, but none were beneficial. Improved the efficiency of A*. Our lights firstly get most of the mosquitos, but then loose some getting back. The greedy is not very good, as it will take a while to get the last few mosquitos.
Group 6
Yigit: <not in class>
Yang: Did not change a lot about the algorithm, but changed the efficiency. Calculate the lie of sight between two points and hash the results. Looking at the small gaps and how the lights go through them. Go through the slightly larger gap, or the slightly smaller gap between the wall the the edge of the board. Determined that going next to the end of the board is the better option. In the cute drawing board, the opening is too small for the lights to see, so the area is invisible, and will only see the mosquitos in to once they leave. In placing the lights, always look at the positions farthest away from the collector
Tim: The waypoints are pruned if they are unneeded, if we have uninteresting sections, our pruning function will combine it. We are also looking at the section size. If the size is too big, just going into the section is not enough. If it is too big, now have the lights do a loop around the section. If the number of lights exceed the lights randomly, if not, place them on the sections based on distance from collector. No current code to check if going to the section if beneficial (if there are no mosquitos). On small holes: Need to think about what the purpose is going through the hole, getting to mosquitos? or bringing mosquitos back? On placement of collector: If the lights arrive at the collector a lot before other lights, maybe the collector is not optimally.
Franklin: Have waypoints that are spaced out for the light to got to. The lights will go from the outside and then converge on the collector. Each of the lights move along their waypoints. The collector moves around based on the waypoints. The collector will be in the middle of the graph of the sections. Vishwa is working on the greedy behavior, if a light is already in a section, do not send another light there.
Vishwa <excused absence>
Group 2:
Jinesh:
Tieram: On Approach for small holes: we are ignoring it and also having problems with it. On sweeping: we are having the collector in the corner and have all the lights move towards the collector. Was concerned about the graphs doubling back on itself. Now, generating waypoints around edges, boxing around it to avoid loosing mosquitos. Second idea, how to handle areas in between. Are currently putting waypoints in between boxed in spaces from wall. Are only pruning nodes in wide open spaces, not around obstacles. Need to prune nodes at a corner. Thinking of pruning the waypoints around walls, or disconnect graph and use A* to get around them. Also having problems with small openings. Right now, putting nodes on each side and “hope for the best”. Thinking of adding a weight to make the lights go slower. Thinking of having a very sparse graph, where we will not get all mosquitos on the first path, or have a very comprehensive graph, and not go out. Our pruning strategy is not thinking about how big the light is. Need to adjust the nodes for line of sight from the light.
Di:
Group 3
Harjot: Have not done a lot of big improvements. Added preemptive stopping around the corners. The lights wait at the waypoints. The lights do not go to the targets that other lights are going to. The light are not placed very optimally, same code from the first week, Dividing the board into horizontal regions and places the lights in each section. The collector is placed on a modified minimum spanning tree using A*.
Tanveer: Satan takes a while to load since it is trying to find the best position for the collector based on the A* of all the walls. On Satan’s beard: When the mosquitos are too near the obstacles, the destination is the waypoint and not the mosquito itself
Hao:
Group 4
Sam: Collector is at the middle. It always is. If there is a wall, the program will try and place it as close to the middle as possible. The lights are placed on the corners. The lights are assigned to the sections they are assigned in the beginning, once done, it will go to the closest section. Had trouble getting around the walls, created a buffer and waiting. Now, the lights will pause when moving to get all the mosquitos to come. Problem with implementation is that there are too many sections. Will now, check if there are mosquitos within 5 from light. If not, then the section is marked as finished/claimed, if not, the light will go it it. Lights will abort early (stop sweeping) if it does not need to sweep section. The sweeping motion is predetermined based on the shape of the section. Might have been better if sweep was based on the locations of the mosquitos. Will have a hunter light to go out and get mosquitos that have been missed. The simulator is slow because of the buffer around the walls causing A* to be slow. The sweeping algorithm will start from the left and go down.
Patrick: The lights will pause after 30 movements, for about 5 rounds. This can be tweaked.
Hari: The lights only visit the collector once, after they have swept the sections to avoid duplicate work. The lights would get stuck in the sections because the sweeper was not handling very small sections well. Going forward, adjust the position of the collector.
Group 5
Marcus: Attempted to find the best way to get to through the board through minimum spanning tree. but the graph has too many leaves and is not as good as what we had before. Going to tweak the way to calculate the way to get the path between the nodes. Going to discard the graph, while keeping the the nodes.
Tanay: The collector is placed,
Lauren: Experimented with new approaches, but none were beneficial. Improved the efficiency of A*. Our lights firstly get most of the mosquitos, but then loose some getting back. The greedy is not very good, as it will take a while to get the last few mosquitos.
Group 6
Yigit: <not in class>
Yang: Did not change a lot about the algorithm, but changed the efficiency. Calculate the lie of sight between two points and hash the results. Looking at the small gaps and how the lights go through them. Go through the slightly larger gap, or the slightly smaller gap between the wall the the edge of the board. Determined that going next to the end of the board is the better option. In the cute drawing board, the opening is too small for the lights to see, so the area is invisible, and will only see the mosquitos in to once they leave. In placing the lights, always look at the positions farthest away from the collector
Thursday, October 24, 2013
Mosquitos 10/22
Group 1:
Tim: We have had three strategies: sweeping, sectioning, and the greedy strategy. This week we have divided the boards into which strategy will be best. Do sectioning first, then sweep, then greedy. Also worked on lifecycle. If the first two strategies has finished, then always shift to greedy if there are mosquitos anywhere. The collector is placed very differently depending on the strategy. Lights stop at corners to let the mosquitos catch up. Right now we are simply removing the nodes that are in areas where the walls are too close. For stealing, if the mosquito was lost or stolen on the way out, it would add a lot more time then if it was lost on the way going in.
Franklin: Generate the minimum spanning tree to place the lights and the collector. This is not yet implemented. Looking at weather there is a direct line of sight between sections to prune them.
Vishwa: We fished many of the bugs, like the light being stuck. Also if the A* fails, then the lights turn off and other lights come in and rescue it. When the light is going to get mosquitos, we have implemented code to not steal mosquitos from other lights. Thinking of switching the orientation of the sweeping. Still not able to sweep or section big maze. If you have more lights, the sweep strategy gets much better. In the spiral maze, the stealing was a problem.
Group 2:
Jinesh: The graph generation algorithm will choose a node near the center and them find the nodes around it and then keep spreading out from there. Have the graph dispersal algorithm for the lights is designed so that the lights will get back to the collector at the same time. One we have generated all the nodes to cover all the board with the least overlapping.
Tieram: Our attempts have reduced how well the implementation works. Attempting to build a tree on the board. Get all nodes, then prune them away by line of sight. The pruning algorithm has a problem if there is no nodes in the line of sight, then there could be a section of the graph is disconnected. The problem with the minimum spanning tree, was that we kept getting really long paths, that were minimum spanning tree, but the edges were too long.
Di: The way we are getting our waypoints for each node, then connect each node. Make a waypoint in between the nodes and the obstacles.
Group 3
Harjot: Optimized the collector this week. It is now a function of the board. We place points all over the board. Draw lines from each of these points to each of the waypoints to get a tree. Then use the minimum spanning tree to place the collector at the roots and the lights at the leaves. The placement of the collector will not change depending on the number of lights. We are still going towards the mosquitos, not on the minimum spanning tree. Working on not leaving any mosquitos behind as it is more costly to get them back. The lights take into account the small spaces between the walls. The lights will collect all they can, and they go back. Only using the minimum spanning tree to place the collector and lights.
Tanveer: Light only go into the closed spaces when they are off and then only grab 5 or so mosquitos and then leave to deposit the mosquitos at the collector. Thinking of putting weights on types of distances, like line of sight distances vs. non line of sight distances.
Hao
Group 4
<ran out of time>
Sam
Patrick
Hari
Group 5
Marcus: The strategy of doing the search space is still being worked on. The graph search does a radial search to see if there is a node that can be pruned out. From this graph, we will place the lights evenly spaced from the collector.
Tanay: improved the placement of the collector. Go through the board and creates nodes at 10x10. the collector is placed __. T Lauren: the biggest problem is still the greedy pass. There is still a lot of redundancy on where the lights are going. Big maze works, but there are issues with the weights of the places by the walls.
Group 6
Yigit: We are positioning the collector by first making a grid on the board. if there is an obstacle, not not draw an edge to it. Take a sample of 25 random points on the graph and place the collector at the smallest distance to every other point.
Yang: Place the lights at the leaves. At each check point look for a mosquito that might need a detour and move there. Has fixed Dijkstra implementation to smooth out path. another idea is when all the lights are going back to the collector, thee lights need to go to the farthest mosquito, have the lights go through all the really small openings to get to the mosquito and then go back through the safe path.
Tim: We have had three strategies: sweeping, sectioning, and the greedy strategy. This week we have divided the boards into which strategy will be best. Do sectioning first, then sweep, then greedy. Also worked on lifecycle. If the first two strategies has finished, then always shift to greedy if there are mosquitos anywhere. The collector is placed very differently depending on the strategy. Lights stop at corners to let the mosquitos catch up. Right now we are simply removing the nodes that are in areas where the walls are too close. For stealing, if the mosquito was lost or stolen on the way out, it would add a lot more time then if it was lost on the way going in.
Franklin: Generate the minimum spanning tree to place the lights and the collector. This is not yet implemented. Looking at weather there is a direct line of sight between sections to prune them.
Vishwa: We fished many of the bugs, like the light being stuck. Also if the A* fails, then the lights turn off and other lights come in and rescue it. When the light is going to get mosquitos, we have implemented code to not steal mosquitos from other lights. Thinking of switching the orientation of the sweeping. Still not able to sweep or section big maze. If you have more lights, the sweep strategy gets much better. In the spiral maze, the stealing was a problem.
Group 2:
Jinesh: The graph generation algorithm will choose a node near the center and them find the nodes around it and then keep spreading out from there. Have the graph dispersal algorithm for the lights is designed so that the lights will get back to the collector at the same time. One we have generated all the nodes to cover all the board with the least overlapping.
Tieram: Our attempts have reduced how well the implementation works. Attempting to build a tree on the board. Get all nodes, then prune them away by line of sight. The pruning algorithm has a problem if there is no nodes in the line of sight, then there could be a section of the graph is disconnected. The problem with the minimum spanning tree, was that we kept getting really long paths, that were minimum spanning tree, but the edges were too long.
Di: The way we are getting our waypoints for each node, then connect each node. Make a waypoint in between the nodes and the obstacles.
Group 3
Harjot: Optimized the collector this week. It is now a function of the board. We place points all over the board. Draw lines from each of these points to each of the waypoints to get a tree. Then use the minimum spanning tree to place the collector at the roots and the lights at the leaves. The placement of the collector will not change depending on the number of lights. We are still going towards the mosquitos, not on the minimum spanning tree. Working on not leaving any mosquitos behind as it is more costly to get them back. The lights take into account the small spaces between the walls. The lights will collect all they can, and they go back. Only using the minimum spanning tree to place the collector and lights.
Tanveer: Light only go into the closed spaces when they are off and then only grab 5 or so mosquitos and then leave to deposit the mosquitos at the collector. Thinking of putting weights on types of distances, like line of sight distances vs. non line of sight distances.
Hao
Group 4
<ran out of time>
Sam
Patrick
Hari
Group 5
Marcus: The strategy of doing the search space is still being worked on. The graph search does a radial search to see if there is a node that can be pruned out. From this graph, we will place the lights evenly spaced from the collector.
Tanay: improved the placement of the collector. Go through the board and creates nodes at 10x10. the collector is placed __. T Lauren: the biggest problem is still the greedy pass. There is still a lot of redundancy on where the lights are going. Big maze works, but there are issues with the weights of the places by the walls.
Group 6
Yigit: We are positioning the collector by first making a grid on the board. if there is an obstacle, not not draw an edge to it. Take a sample of 25 random points on the graph and place the collector at the smallest distance to every other point.
Yang: Place the lights at the leaves. At each check point look for a mosquito that might need a detour and move there. Has fixed Dijkstra implementation to smooth out path. another idea is when all the lights are going back to the collector, thee lights need to go to the farthest mosquito, have the lights go through all the really small openings to get to the mosquito and then go back through the safe path.
| boxes/ lines | Big maze | Satan | |
| 1 | 751 +/- | 321 | |
| 2 | |||
| 3 | 277 | 1217 | 235 |
| 4 | |||
| 5 | 431 | 1664 | 560 |
| 6 | 202 | 918 | 329 |
Sunday, October 20, 2013
Mosquito 10/17
Group 1:
Tim: The two strategies are good, since some of the boards require a large amount of calculation time in the beginning. Another strategy, make the board into a graph, but prune out all of the obstacles. Divide them up into sections and then make a minimum spanning tree. Use the minimum spanning tree to determine the order of points to visit. Assign the collector at the middle, place the lights at the end and the spaces between the end and the collectors. Need to determine which sections are redundant. Need to add or remove midpoints to the sections depending on the area of the sections.
Franklin: Not currently implemented minimum spanning tree. So, use waypoints instead. Not all of the waypoints are being visited, if they are too close to the wall, they will be skipped.
Vishwa: Our A* implementation fails when the slope is -1. Current strategy, lights start and then continue until it hits a wall, then it goes right and up until it gets around a wall. They have a buffer around the edges of the walls. The lights will go back to the collector, wait there 10 rounds and then switch to the greedy strategy. Lights are placed equidistant on the left side and the collector is in the right size. The lights check that they are not stealing mosquitos from the other lights.
Group 2:
Jinesh: We make a fine grid, start at one point, then look for any nodes in a certain radius, within the radius of the light. Then go to the next one in the line of sight, biased toward the center. Once the lights have made it to the collector, look to see which nodes have not been visited. Working on experimenting with lowest and highest density of mosquitos
Tieram: Need to refactor code. Working on pruning away the leaves of the tree. On the minimum spanning tree, we cases where the diagonal distance is not taken into consideration. Hoping to change the algorithm to start in the center.
Di: In the case of the really small openings, play around with the speed to make sure all of the mosquitos are past the openings.
Group 3
Harjot: have the code that will move the lights around, but not optimize the paths.
Tanveer: Two new things: working on corner cases. Implemented a handoff function for the collector. In small opening case, the lights collect everything outside the box first, then goes to get the next. Creates a new set of waypoints at the openings. Collector is placed on the point closest to the A* points.
Hao
Group 4
Sam: Lights will be placed in the first two sections if there are only two lights. The lights will sweep their section and then go to the next section. Once all the sections have been swept, the lights will go to the collector. Once everything has been claimed, thinking of making another mode to go out and get the final mosquitos. Lights have a start point and an end point of the section to tell the light where to sweep and when it is done.
Patrick: Currently having a bug that is making the light at the collector move back and forth. We need to think about efficient movements between sections. When there are a lot of walls, a catcher strategy might be better then a sweeping strategy.
Hari: fixed bugs in code. paths are determined by A*. Collector is placed in the middle. Planning on placing the collector at most reachable point from all other points. The sections are stored in an array. Have a list of unclaimed sections for the lights to look to go to next. Need to
Group 5
Marcus: New Strategy, trying to formulate the problem as a search optimization of the path the lights are moving. Minimizing the maximum length of the longest path of the light to the collector. Equally space the lights from the collector. Has been having trouble getting the paths equal distance.
Tanay: Check if lights are stuck, then force them out.
Lauren: working on making the lights go along the wall instead of the zig-zag on the board. It works well with the boards with the lights spanning over the board. Still having the issue that if they are not using A*, the lights go too close to the wall and loose mosquitos. A* will take a long time to calculate and freeze the board. Once fixed bug where the lights loose mosquitos, look into not going back to collectors before switching to greedy mode.
Group 6
Yigit:
Yang: Moves the collector at the largest empty space. This makes a sort of random placement.Adding a weight to small openings to discourage lights from going through the openings. The lights stop because they will stay if a movement will result in no longer seeing the mosquito. A light might wait forever if the opening is too small. So, added a time component, that the light will go through the opening if it has been waiting more then 10 rounds.
Tim: The two strategies are good, since some of the boards require a large amount of calculation time in the beginning. Another strategy, make the board into a graph, but prune out all of the obstacles. Divide them up into sections and then make a minimum spanning tree. Use the minimum spanning tree to determine the order of points to visit. Assign the collector at the middle, place the lights at the end and the spaces between the end and the collectors. Need to determine which sections are redundant. Need to add or remove midpoints to the sections depending on the area of the sections.
Franklin: Not currently implemented minimum spanning tree. So, use waypoints instead. Not all of the waypoints are being visited, if they are too close to the wall, they will be skipped.
Vishwa: Our A* implementation fails when the slope is -1. Current strategy, lights start and then continue until it hits a wall, then it goes right and up until it gets around a wall. They have a buffer around the edges of the walls. The lights will go back to the collector, wait there 10 rounds and then switch to the greedy strategy. Lights are placed equidistant on the left side and the collector is in the right size. The lights check that they are not stealing mosquitos from the other lights.
Group 2:
Jinesh: We make a fine grid, start at one point, then look for any nodes in a certain radius, within the radius of the light. Then go to the next one in the line of sight, biased toward the center. Once the lights have made it to the collector, look to see which nodes have not been visited. Working on experimenting with lowest and highest density of mosquitos
Tieram: Need to refactor code. Working on pruning away the leaves of the tree. On the minimum spanning tree, we cases where the diagonal distance is not taken into consideration. Hoping to change the algorithm to start in the center.
Di: In the case of the really small openings, play around with the speed to make sure all of the mosquitos are past the openings.
Group 3
Harjot: have the code that will move the lights around, but not optimize the paths.
Tanveer: Two new things: working on corner cases. Implemented a handoff function for the collector. In small opening case, the lights collect everything outside the box first, then goes to get the next. Creates a new set of waypoints at the openings. Collector is placed on the point closest to the A* points.
Hao
Group 4
Sam: Lights will be placed in the first two sections if there are only two lights. The lights will sweep their section and then go to the next section. Once all the sections have been swept, the lights will go to the collector. Once everything has been claimed, thinking of making another mode to go out and get the final mosquitos. Lights have a start point and an end point of the section to tell the light where to sweep and when it is done.
Patrick: Currently having a bug that is making the light at the collector move back and forth. We need to think about efficient movements between sections. When there are a lot of walls, a catcher strategy might be better then a sweeping strategy.
Hari: fixed bugs in code. paths are determined by A*. Collector is placed in the middle. Planning on placing the collector at most reachable point from all other points. The sections are stored in an array. Have a list of unclaimed sections for the lights to look to go to next. Need to
Group 5
Marcus: New Strategy, trying to formulate the problem as a search optimization of the path the lights are moving. Minimizing the maximum length of the longest path of the light to the collector. Equally space the lights from the collector. Has been having trouble getting the paths equal distance.
Tanay: Check if lights are stuck, then force them out.
Lauren: working on making the lights go along the wall instead of the zig-zag on the board. It works well with the boards with the lights spanning over the board. Still having the issue that if they are not using A*, the lights go too close to the wall and loose mosquitos. A* will take a long time to calculate and freeze the board. Once fixed bug where the lights loose mosquitos, look into not going back to collectors before switching to greedy mode.
Group 6
Yigit:
Yang: Moves the collector at the largest empty space. This makes a sort of random placement.Adding a weight to small openings to discourage lights from going through the openings. The lights stop because they will stay if a movement will result in no longer seeing the mosquito. A light might wait forever if the opening is too small. So, added a time component, that the light will go through the opening if it has been waiting more then 10 rounds.
Thursday, October 17, 2013
Mosquito 10/15
Group 1:
Tim: Our value added is the sectioning approach. Basing the waypoints on the sections. Based the sections on extending the lines of the intersections. So, now looking on each point on the screen and looks at which lines are around it. Using this to assigns it to a section. Once using sections, we are trying to sweep the board.
Franklin: Still don’t have something fully functional. Has A* working, has sectioning working. The way we were going through the sections were very naive. Thinking about changing the light roles based on the life cycle. Thinking about a collector light, a scavenger lights and sweeper lights. Also creating a buffer by extending the lines like group 5.
Vishwa: Our scanning sweeping strategy makes the lights move around the obstacle to the other side of it, and then send it continuing on the same path. What about placing the collector in location with the minimum obstacle density
Group 2:
Jinesh <Not in class>
Tieram: <Excused absence>
Di: Strategy was to divide the space with way points, and use that to make a tree with the collector as the root. Then use minimum spanning tree to move the lights around. Now, they have optimized the graph to avoid edges. The lights only traverse the tree. Thinking about added dynamic functionality to have the lights go back to a node to get the mosquitos. Thinking about using different roles. Could not get the tree connected with the big maze because of the small hole.
To consider: life cycle for lights, or have the light see if there are any mosquitos in the edge it is about to traverse, so maybe skip that branch. Also prune minimum spanning tree to take into account light radius.
Group 3
Harjot: You can move the light to be over the collector later in the game. Lights going toward the closest mosquito, farther then 20 units, taking into account the barriers and the other lights. Using A* to avoid the obstacles. . Have not worked on placing the lights. Has a lagging function where the lights will wait at a corner for all the mosquitos. Also haves a smoothing function where the lights stay on its path for a few rounds. There seems to be a bug in the A*. Have not thought about initial placement of the collector.
Tanveer: If the opening is too small, see it as a solid wall. To calculate the A* and the ways points for a light on the edge, we create a new waypoint just for that light at the moment.
Hao
Group 4
Sam: Make sure there are at least as many sections as lights. Each light has a start point, once the light has returned to the collector, move the light to the section closest to the start point and move the light to the start point of the next section.
Patrick: We are having a issue with returning to the collector. Having a move by more then one error. We need to be able to move from section to section. If there are more sections then lights, then you need to be able to send the lights to the closest section
Hari: Mostly done but has bug. Partition board for sweeping and then have lights go to that section. Working to collapse sections if they have a light of sight between them.
Group 5
Marcus
Tanay: the fundamental innovations are: changed how we move in A* and how to avoid corners. Lights will go around the corners in a certain radius.
Lauren: lights being placed along a graph around that sweeps through the board. Lights will go along the path once, if there are still mosquitos afterward, then they go greedy. Are no always using A*, only when near a wall. No longer using the wall extension. Our checks against the walls are not working very well. One light is parked at the collector, the lights brings the mosquitos to the light by the collector and leaves. The collector is not placed very well right now.
Group 6
Yigit <Not in class>
Yang: collector is still in the center. The lights now see the furthest mosquitos. Lights will move to the mosquitos that are the farthest to the collector so that as the lights move closer to the collector, they will get more mosquitos, saving time. Has a lot of problems with the big maze board. Originally did not think the bottom 100 row as a row to be able to move to. Thinking of placing the light in a minimum spanning tree. Turns the lights off after the light has moved to the collector and then needs to move back outside to collect more mosquitos.
Tim: Our value added is the sectioning approach. Basing the waypoints on the sections. Based the sections on extending the lines of the intersections. So, now looking on each point on the screen and looks at which lines are around it. Using this to assigns it to a section. Once using sections, we are trying to sweep the board.
Franklin: Still don’t have something fully functional. Has A* working, has sectioning working. The way we were going through the sections were very naive. Thinking about changing the light roles based on the life cycle. Thinking about a collector light, a scavenger lights and sweeper lights. Also creating a buffer by extending the lines like group 5.
Vishwa: Our scanning sweeping strategy makes the lights move around the obstacle to the other side of it, and then send it continuing on the same path. What about placing the collector in location with the minimum obstacle density
Group 2:
Jinesh <Not in class>
Tieram: <Excused absence>
Di: Strategy was to divide the space with way points, and use that to make a tree with the collector as the root. Then use minimum spanning tree to move the lights around. Now, they have optimized the graph to avoid edges. The lights only traverse the tree. Thinking about added dynamic functionality to have the lights go back to a node to get the mosquitos. Thinking about using different roles. Could not get the tree connected with the big maze because of the small hole.
To consider: life cycle for lights, or have the light see if there are any mosquitos in the edge it is about to traverse, so maybe skip that branch. Also prune minimum spanning tree to take into account light radius.
Group 3
Harjot: You can move the light to be over the collector later in the game. Lights going toward the closest mosquito, farther then 20 units, taking into account the barriers and the other lights. Using A* to avoid the obstacles. . Have not worked on placing the lights. Has a lagging function where the lights will wait at a corner for all the mosquitos. Also haves a smoothing function where the lights stay on its path for a few rounds. There seems to be a bug in the A*. Have not thought about initial placement of the collector.
Tanveer: If the opening is too small, see it as a solid wall. To calculate the A* and the ways points for a light on the edge, we create a new waypoint just for that light at the moment.
Hao
Group 4
Sam: Make sure there are at least as many sections as lights. Each light has a start point, once the light has returned to the collector, move the light to the section closest to the start point and move the light to the start point of the next section.
Patrick: We are having a issue with returning to the collector. Having a move by more then one error. We need to be able to move from section to section. If there are more sections then lights, then you need to be able to send the lights to the closest section
Hari: Mostly done but has bug. Partition board for sweeping and then have lights go to that section. Working to collapse sections if they have a light of sight between them.
Group 5
Marcus
Tanay: the fundamental innovations are: changed how we move in A* and how to avoid corners. Lights will go around the corners in a certain radius.
Lauren: lights being placed along a graph around that sweeps through the board. Lights will go along the path once, if there are still mosquitos afterward, then they go greedy. Are no always using A*, only when near a wall. No longer using the wall extension. Our checks against the walls are not working very well. One light is parked at the collector, the lights brings the mosquitos to the light by the collector and leaves. The collector is not placed very well right now.
Group 6
Yigit <Not in class>
Yang: collector is still in the center. The lights now see the furthest mosquitos. Lights will move to the mosquitos that are the farthest to the collector so that as the lights move closer to the collector, they will get more mosquitos, saving time. Has a lot of problems with the big maze board. Originally did not think the bottom 100 row as a row to be able to move to. Thinking of placing the light in a minimum spanning tree. Turns the lights off after the light has moved to the collector and then needs to move back outside to collect more mosquitos.
Thursday, October 10, 2013
Mosquito 10/8
Group 1:
Tim:
Franklin: Section idea, divide up the board into different sections. It was very hard to break up the board into the sections depending on the obstacles. You don’t know where the lines intersect to make the boundary.
Vishwa: Other approach of navigating across obstacles, it is mostly working, but will fail if you have a very convoluted obstacle. the buffer also needs to be dynamic, so that it takes into account other obstacles nearby.
Group 2:
Jinesh: having problems when the nodes are placed very close to the walls which causes problems as the mosquito loose the light. Want to play with changing the starting locations of the lights and placing the nodes better
Tieram: Basic idea is to build the board as a graph and finding the minimum spanning tree. Planing the lights at the farthest corners. Placing the collector at the closest point to all of the leafs.
Di: Also working on placing the nodes based on density of the mosquitos
Group 3
Harjot: We divide the board into regions naively. The lights are in each region and placing the collector in a unoccupied region. The lights will look for mosquitos based on obstacles and the A* distance. The lights only go to the collector once all the mosquitos are at the lights. Collision detection will really help and recalculating more often.
Tanveer:
Hao
Group 4
Sam: Worked on the sweeping algorithm. The light will go to a starting point in the region and then it will sweep back and forth always moving right and up and down. If one mosquito goes from one section to another or is missed, then the light does not go back or change its behavior
Patrick: Strategy is to statically sweep the board, broken up into three parts.
Hari: Breaking the board into different sections with the obstacles included. If there are more sections then lights, sweep the biggest sections, then go to the section easiest to go to.
Group 5
Marcus: Finding that the lights sometimes get stuck.
Tanay: also looked into a MST and not making edges between vertices.
Lauren: Our strategy is to use A*. Now, makes one sweeping motion throughout the board. If the light finds a wall, then use A* to find the best way around it. Divided the board into regions
Group 6
Yigit
Yang: Last time we were trying to use Dijkstra and connect the board like a graph. Now, making each node bigger and calculate the lines to get to the collector. At the corner of the obstacles try to make the line have a greater angle to avoid losing mosquitos . The collector is in the center. Is looking into a “diversion” algorithm to find mosquitos that are around before going back to the collector. Placed the lights based on the furthest places from the collector
Tim:
Franklin: Section idea, divide up the board into different sections. It was very hard to break up the board into the sections depending on the obstacles. You don’t know where the lines intersect to make the boundary.
Vishwa: Other approach of navigating across obstacles, it is mostly working, but will fail if you have a very convoluted obstacle. the buffer also needs to be dynamic, so that it takes into account other obstacles nearby.
Group 2:
Jinesh: having problems when the nodes are placed very close to the walls which causes problems as the mosquito loose the light. Want to play with changing the starting locations of the lights and placing the nodes better
Tieram: Basic idea is to build the board as a graph and finding the minimum spanning tree. Planing the lights at the farthest corners. Placing the collector at the closest point to all of the leafs.
Di: Also working on placing the nodes based on density of the mosquitos
Group 3
Harjot: We divide the board into regions naively. The lights are in each region and placing the collector in a unoccupied region. The lights will look for mosquitos based on obstacles and the A* distance. The lights only go to the collector once all the mosquitos are at the lights. Collision detection will really help and recalculating more often.
Tanveer:
Hao
Group 4
Sam: Worked on the sweeping algorithm. The light will go to a starting point in the region and then it will sweep back and forth always moving right and up and down. If one mosquito goes from one section to another or is missed, then the light does not go back or change its behavior
Patrick: Strategy is to statically sweep the board, broken up into three parts.
Hari: Breaking the board into different sections with the obstacles included. If there are more sections then lights, sweep the biggest sections, then go to the section easiest to go to.
Group 5
Marcus: Finding that the lights sometimes get stuck.
Tanay: also looked into a MST and not making edges between vertices.
Lauren: Our strategy is to use A*. Now, makes one sweeping motion throughout the board. If the light finds a wall, then use A* to find the best way around it. Divided the board into regions
Group 6
Yigit
Yang: Last time we were trying to use Dijkstra and connect the board like a graph. Now, making each node bigger and calculate the lines to get to the collector. At the corner of the obstacles try to make the line have a greater angle to avoid losing mosquitos . The collector is in the center. Is looking into a “diversion” algorithm to find mosquitos that are around before going back to the collector. Placed the lights based on the furthest places from the collector
Monday, October 7, 2013
Mosquitos 10/3
Group 1:
Tim: lights add the barrier to a stack of problems to solve. Program then tries to find the endpoint. If the end point connects to a new barrier, it will add that onto the stack. A future strategy will break the board into grids based on the barriers and add a light to the section. Not convinced with the strategy of lights going to highest mosquito density
Franklin: to place the collector in the grid strategy, put it in between sections. Planning on using other data structures to help calculate the different sections
Vishwa: avoiding the obstacles strategy is unaffected by the number of lights. When you are trying to move around the barriers you can cut of mosquitoes following you. to fix this they are planning on creating a buffer to keep the mosquitoes
Group 2:
Jinesh: Wanted to keep with the sweeping strategy. Trying to make a circuit to cover the board. The key to this is to intelligently place the nodes on the board.
Tieram: Noticed that there are two aspects, one where are the mosquitoes, and two how to analyze the board with the obstacles. Tries to pre-analyze the board and use these to sweep the board. Using a minimum spanning tree, to place the collector. You can have a lot of issues with repeating work, maybe set up a circuit for the lights. Currently setting up nodes by the ends of the barriers to avoid losing mosquitos.
Di: <Not in class>
Group 3
Harjot: three parts of the strategy, target, acquisition & collection; Placing the collector is very simple right now, either in the center or in an empty space.
Tanveer: using a variation of A* with the barriers. Find an optimal strategy between the start and end point for each light using waypoints. The waypoints are placed based on the end points of the obstacles. waypoints are calculated at the beginning based on the obstacles.
Hao
Group 4
Sam: Is thinking of dividing up the board into better quadrants. Using mosquito density to avoid going back into a squares that have already been hit, but maybe a different indicator might be better.
Patrick: realized that it would be very hard to make a dynamic program work. Thinking about using A* and divide up the grid into quadrants
Hari: Make the lights closest to the most populated area collect all the mosquitoes and then use A* to figure out the best path to the collector
Group 5
Marcus: A* nodes are each 1 unit square. Have a buffer size around the ends of the barriers.
Tanay - The change in capture target percentage should maybe affect strategy. Need to optimize the A* since it takes a long time. Will recalculate where to send the light after it gets to the collector. Want to better place the lights depending on population and barriers
Lauren: kept greedy strategy, but added A*. Had the problem of going too close to walls, so are keeping track of the walls too. Once the light has hit the collector, the lights will go the most populated area that another light is not already going through. The lights stay off until it gets there.
Group 6
Yigit: <not in class>
Yang: The lights start from edges then go to the center where the collector is. It will then go back out the the most populated area. Lights are randomly placed on the board. Pre-computes paths the the lights to take to get to each area of the board using Dykstra’s algorithm.
Tim: lights add the barrier to a stack of problems to solve. Program then tries to find the endpoint. If the end point connects to a new barrier, it will add that onto the stack. A future strategy will break the board into grids based on the barriers and add a light to the section. Not convinced with the strategy of lights going to highest mosquito density
Franklin: to place the collector in the grid strategy, put it in between sections. Planning on using other data structures to help calculate the different sections
Vishwa: avoiding the obstacles strategy is unaffected by the number of lights. When you are trying to move around the barriers you can cut of mosquitoes following you. to fix this they are planning on creating a buffer to keep the mosquitoes
Group 2:
Jinesh: Wanted to keep with the sweeping strategy. Trying to make a circuit to cover the board. The key to this is to intelligently place the nodes on the board.
Tieram: Noticed that there are two aspects, one where are the mosquitoes, and two how to analyze the board with the obstacles. Tries to pre-analyze the board and use these to sweep the board. Using a minimum spanning tree, to place the collector. You can have a lot of issues with repeating work, maybe set up a circuit for the lights. Currently setting up nodes by the ends of the barriers to avoid losing mosquitos.
Di: <Not in class>
Group 3
Harjot: three parts of the strategy, target, acquisition & collection; Placing the collector is very simple right now, either in the center or in an empty space.
Tanveer: using a variation of A* with the barriers. Find an optimal strategy between the start and end point for each light using waypoints. The waypoints are placed based on the end points of the obstacles. waypoints are calculated at the beginning based on the obstacles.
Hao
Group 4
Sam: Is thinking of dividing up the board into better quadrants. Using mosquito density to avoid going back into a squares that have already been hit, but maybe a different indicator might be better.
Patrick: realized that it would be very hard to make a dynamic program work. Thinking about using A* and divide up the grid into quadrants
Hari: Make the lights closest to the most populated area collect all the mosquitoes and then use A* to figure out the best path to the collector
Group 5
Marcus: A* nodes are each 1 unit square. Have a buffer size around the ends of the barriers.
Tanay - The change in capture target percentage should maybe affect strategy. Need to optimize the A* since it takes a long time. Will recalculate where to send the light after it gets to the collector. Want to better place the lights depending on population and barriers
Lauren: kept greedy strategy, but added A*. Had the problem of going too close to walls, so are keeping track of the walls too. Once the light has hit the collector, the lights will go the most populated area that another light is not already going through. The lights stay off until it gets there.
Group 6
Yigit: <not in class>
Yang: The lights start from edges then go to the center where the collector is. It will then go back out the the most populated area. Lights are randomly placed on the board. Pre-computes paths the the lights to take to get to each area of the board using Dykstra’s algorithm.
Thursday, October 3, 2013
Mosquito 10/1
Group 1:
Tim:
Franklin: Implemented three algorithms, have lights move right, left and then converge in the center. Other, move the lights in a spiral, from the top to the center, where the collector is. In the spiral, the number of lights does not affect the strategy, unless you run out of lights. If you miss a mosquito the score doubles as you have to run another spiral. One observation is that you don’t want to move if you don’t need to, otherwise the power increases needlessly. Demo’ed Tim’s implementation where lights go left to right and then back to center.
Vishwa: Position the lights on a diagonal, and then moves them in a left/right motion for a number of rounds then move them to the collector in the center of the board. Works well if you have at least 3 lights, if less, then the lights move in a square pattern. Demo’ed square strategy for 2 .
Group 2:
Jinesh: When the lights are less then three, there needs to be a special strategy. When there is more lights then you need turn them off, turn them off to conserve power and rounds.
Tieram: put the lights on the top and move them down and converge on the bottom center where the collector is. Demo’ed 2 light strategy, random. five lights, sweep town and then over to collector.
Di:
Group 3
Harjot: Also using the sweeping strategy, diving the board into sections for each light, might be overlapping. Trying to find the shortest distance to the mosquito outside the light’s radius to move to it. We turn the lights on and off too. The collector is in the center. There is a light always at the collector. Demo’ed strategy.
Tanveer
Hao
Group 4
Sam: Two strategies, sweeper with two lights oscillate back and forth to collect everything.
Patrick: Demo’ed strategy.
Hari: Also has a light at the collector to make sure the mosquito made it into the collector. Other strategy was to break the board into quadrants, the collector is in the most populated quadrant. The lights bring the mosquito to the collector and then the turn itself off and go to the most populated quadrant. Positioning the collector dynamically. Demo’ed strategy
Group 5
Marcus: Greedy implementation, the lights will go to grab extra mosquitos after the sweep is finished based on where has the most mosquitos.
Tanay: <NOT IN CLASS>
Lauren: Had a vertical sweep and a radial light pattern. Some issue with the mosquito not moving into the collector. Demo’ed strategy
Group 6
Yigit: Did a left to right sweep.
Yang: noticed that sweep will not work for two lights. Tried to make a circle strategy but also did not work for two lights. with six lights you can start at both the top and bottom and sweep towards the center. For the two lights, turn the light off when it gets close to collector. Demo’ed stratgy
Tim:
Franklin: Implemented three algorithms, have lights move right, left and then converge in the center. Other, move the lights in a spiral, from the top to the center, where the collector is. In the spiral, the number of lights does not affect the strategy, unless you run out of lights. If you miss a mosquito the score doubles as you have to run another spiral. One observation is that you don’t want to move if you don’t need to, otherwise the power increases needlessly. Demo’ed Tim’s implementation where lights go left to right and then back to center.
Vishwa: Position the lights on a diagonal, and then moves them in a left/right motion for a number of rounds then move them to the collector in the center of the board. Works well if you have at least 3 lights, if less, then the lights move in a square pattern. Demo’ed square strategy for 2 .
Group 2:
Jinesh: When the lights are less then three, there needs to be a special strategy. When there is more lights then you need turn them off, turn them off to conserve power and rounds.
Tieram: put the lights on the top and move them down and converge on the bottom center where the collector is. Demo’ed 2 light strategy, random. five lights, sweep town and then over to collector.
Di:
Group 3
Harjot: Also using the sweeping strategy, diving the board into sections for each light, might be overlapping. Trying to find the shortest distance to the mosquito outside the light’s radius to move to it. We turn the lights on and off too. The collector is in the center. There is a light always at the collector. Demo’ed strategy.
Tanveer
Hao
Group 4
Sam: Two strategies, sweeper with two lights oscillate back and forth to collect everything.
Patrick: Demo’ed strategy.
Hari: Also has a light at the collector to make sure the mosquito made it into the collector. Other strategy was to break the board into quadrants, the collector is in the most populated quadrant. The lights bring the mosquito to the collector and then the turn itself off and go to the most populated quadrant. Positioning the collector dynamically. Demo’ed strategy
Group 5
Marcus: Greedy implementation, the lights will go to grab extra mosquitos after the sweep is finished based on where has the most mosquitos.
Tanay: <NOT IN CLASS>
Lauren: Had a vertical sweep and a radial light pattern. Some issue with the mosquito not moving into the collector. Demo’ed strategy
Group 6
Yigit: Did a left to right sweep.
Yang: noticed that sweep will not work for two lights. Tried to make a circle strategy but also did not work for two lights. with six lights you can start at both the top and bottom and sweep towards the center. For the two lights, turn the light off when it gets close to collector. Demo’ed stratgy
Tuesday, October 1, 2013
Tournamnet Results
| SINGLE PLAYER | ||||||||||||
| [X=20, Y=20, p=0.01, q=0.02, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | 24,263 | 21,665 | 23,574 | 21,342 | 23,026 | 21,905 | 23,656 | 21,203 | 19,281 | 21,805 | 22,172 | N/A |
| Group2Player | 30,706 | 31,245 | 33,916 | 34,044 | 32,777 | 31,255 | 28,837 | 34,120 | 32,222 | 34,647 | 32,377 | N/A |
| ShyPlayer | 18,089 | 18,089 | 18,732 | 16,319 | 17,978 | 18,087 | 18,442 | 19,411 | 18,259 | 17,956 | 18,136 | N/A |
| RainbowCastle | 29,154 | 29,079 | 28,823 | 28,598 | 27,236 | 30,219 | 28,399 | 29,402 | 27,781 | 28,627 | 28,732 | N/A |
| Group5Flood | 19,292 | 20,211 | 21,711 | 21,712 | 19,897 | 21,130 | 21,557 | 19,063 | 19,064 | 15,162 | 19,880 | N/A |
| Group6Player | 135,625 | 142,218 | 135,459 | 132,250 | 136,031 | 140,052 | 139,470 | 140,637 | 138,703 | 142,386 | 138,283 | N/A |
| [X=50, Y=50, p=0.01, q=0.02, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | 145,806 | 147,055 | 142,165 | 140,755 | 140,910 | 188,169 | 138,992 | 142,252 | 144,973 | 145,320 | 147,640 | N/A |
| Group2Player | 211,488 | 200,760 | 207,271 | 213,591 | 210,187 | 212,493 | 217,644 | 207,743 | 212,736 | 208,988 | 210,290 | N/A |
| ShyPlayer | 108,721 | 113,998 | 114,137 | 111,990 | 113,187 | 114,556 | 114,582 | 110,399 | 113,798 | 110,019 | 112,539 | N/A |
| RainbowCastle | 182,096 | 179,669 | 178,757 | 188,982 | 185,137 | 182,128 | 185,220 | 186,014 | 185,129 | 180,707 | 183,384 | N/A |
| Group5Flood | 121,143 | 117,852 | 118,546 | 125,591 | 111,132 | 119,097 | 125,600 | 123,797 | 123,093 | 113,289 | 119,914 | N/A |
| Group6Player | 868,226 | 869,125 | 873,555 | 861,578 | 869,813 | 858,977 | 867,864 | 863,777 | 872,176 | 858,873 | 866,396 | N/A |
| [X=20, Y=20, p=0.001, q=0.002, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (201) | (191) | (121) | (201) | (110) | (282) | (120) | (292) | (282) | (110) | 0 | (174) |
| Group2Player | (36) | (63) | (46) | (36) | (26) | (143) | (46) | (27) | (400) | (36) | 0 | (78) |
| ShyPlayer | (223) | (415) | (282) | (11) | (467) | (114) | (250) | (272) | (2,016) | (1,049) | 0 | (464) |
| RainbowCastle | (71) | (368) | (174) | (265) | (4,042) | (274) | (334) | (174) | (74) | (265) | 0 | (549) |
| Group5Flood | (189) | (210) | (237) | (119) | (210) | (115) | (301) | (119) | (269) | (210) | 0 | (180) |
| Group6Player | 4,385 | 4,802 | 8,407 | 6,244 | 5,749 | 6,392 | 9,554 | 5,414 | 8,995 | 7,705 | 6,765 | N/A |
| [X=20, Y=20, p=0.005, q=0.01, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | 13,351 | 13,201 | 13,639 | 16,789 | 95,374 | 13,323 | 12,553 | 13,894 | 13,960 | 12,886 | 21,897 | N/A |
| Group2Player | 20,196 | 21,190 | 22,024 | 24,027 | 23,657 | 20,712 | 21,873 | 21,593 | 19,342 | 21,700 | 21,631 | N/A |
| ShyPlayer | 11,893 | 11,019 | 10,880 | 11,005 | 11,760 | 10,960 | 11,232 | 11,571 | 13,130 | 11,971 | 11,542 | N/A |
| RainbowCastle | 16,831 | 17,463 | 16,508 | 16,639 | 17,559 | 16,965 | 14,509 | 17,836 | 15,474 | 17,541 | 16,733 | N/A |
| Group5Flood | 13,889 | 16,682 | 14,120 | 15,206 | 15,610 | 13,684 | 15,484 | 13,804 | 14,779 | 16,782 | 15,004 | N/A |
| Group6Player | 138,947 | 133,263 | 129,746 | 129,243 | 130,374 | 127,318 | 128,783 | 135,082 | 129,927 | 128,308 | 131,099 | N/A |
| [X=50, Y=50, p=1, q=0.0, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | 454,942 | 462,238 | 459,009 | 460,415 | 451,631 | 448,555 | 462,069 | 452,260 | 433,876 | 438,142 | 452,314 | N/A |
| Group2Player | 570,522 | 577,629 | 588,720 | 605,455 | 547,924 | 587,315 | 580,861 | 599,123 | 568,094 | 578,831 | 580,447 | N/A |
| ShyPlayer | 258,682 | 267,249 | 261,654 | 262,504 | 263,373 | 265,610 | 261,457 | 258,918 | 260,812 | 266,618 | 262,688 | N/A |
| RainbowCastle | 490,809 | 494,575 | 480,989 | 501,229 | 478,268 | 500,868 | 505,217 | 508,880 | 489,249 | 494,763 | 494,485 | N/A |
| Group5Flood | 286,654 | 271,768 | 250,471 | 253,373 | 283,187 | 286,705 | 274,472 | 286,977 | 302,436 | 266,630 | 276,267 | N/A |
| Group6Player | 490 | 704,521 | 706,044 | 687,406 | 682,919 | 715,546 | 698,705 | 697,669 | 692,832 | 673,409 | 625,954 | N/A |
| [X=20, Y=20, p=0.01, q=0.02, maxrounds=10000, K = 20] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | 23,003 | 23,224 | 19,589 | 19,073 | 22,710 | 21,507 | 24,494 | 22,172 | 22,037 | 22,784 | 22,059 | N/A |
| Group2Player | 30,710 | 34,095 | 34,841 | 32,789 | 33,276 | 33,174 | 33,805 | 33,863 | 31,059 | 31,261 | 32,887 | N/A |
| ShyPlayer | 19,562 | 18,592 | 19,164 | 17,119 | 18,233 | 17,887 | 19,238 | 19,431 | 18,437 | 16,679 | 18,434 | N/A |
| RainbowCastle | 28,749 | 27,177 | 31,130 | 30,811 | 29,823 | 29,547 | 28,264 | 28,957 | 29,068 | 31,407 | 29,493 | N/A |
| Group5Flood | 18,417 | 20,626 | 18,455 | 20,522 | 15,242 | 16,042 | 15,532 | 18,747 | 19,853 | 19,123 | 18,256 | N/A |
| Group6Player | 103,414 | 94,927 | 95,816 | 101,119 | 100,741 | 97,058 | 92,860 | 95,907 | 96,034 | 96,461 | 97,434 | N/A |
| [X=20, Y=20, p=0.01, q=0.02, maxrounds=10000, M = 250] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | 10361 | 9261 | 9825 | 9465 | 58681 | 7271 | 16193 | 9458 | 9146 | 9001 | 14,866 | N/A |
| Group2Player | 17213 | 15209 | 15714 | 16584 | 14873 | 15591 | 17216 | 15753 | 16322 | 17134 | 16,161 | N/A |
| ShyPlayer | 12623 | 12288 | 12648 | 12530 | 12116 | 10005 | 12226 | 12272 | 11895 | 11223 | 11,983 | N/A |
| RainbowCastle | 12,522 | 12,591 | 12,352 | 13,181 | 13,572 | 13,480 | 13,252 | 11,603 | 12,349 | 11,571 | 12,647 | N/A |
| Group5Flood | 8,871 | 7,462 | 8,269 | 6,916 | 6,722 | 8,237 | 9,027 | 8,881 | 7,836 | 9,316 | 8,154 | N/A |
| Group6Player | 61,232 | 64,284 | 61,830 | 63,120 | 59,013 | 61,843 | 64,877 | 62,853 | 64,780 | 63,388 | 62,722 | N/A |
| MULTI-PLAYER | ||||||||||||
| [X=20, Y=20, p=0.01, q=0.02, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (6,257) | (3,289) | (1,133) | (2,209) | (2,675) | (1,529) | (2,508) | (5,783) | (518) | (1,650) | 0 | (2,755) |
| Group2Player | (15,999) | (3,829) | (1,966) | (4,008) | (5,872) | (4,067) | (2,198) | (1,610) | (4,971) | (4,961) | 0 | (4,498) |
| ShyPlayer | (3,798) | (1,379) | (2,009) | (1,940) | (916) | (2,867) | (993) | (10,774) | (5,284) | (3,557) | 0 | (3,047) |
| RainbowCastle | 27,989 | (2,362) | (2,798) | 29,812 | 28,184 | (1,069) | (2,182) | 32,620 | (2,218) | (4,284) | 29,651 | (2,486) |
| Group5Flood | (13,959) | 16,931 | 18,955 | (3,054) | (3,808) | 17,675 | 20,226 | (1,156) | 23,187 | 19,196 | 19,362 | (6,258) |
| Group6Player | (1,073) | (4,424) | (2,310) | (1,692) | (1,380) | (981) | (1,297) | (1,474) | (915) | (578) | 0 | (1,612) |
| [X=50, Y=50, p=0.01, q=0.02, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (1,988) | (3,866) | (4,636) | (8,556) | (5,848) | (1,977) | (3,090) | (1,671) | (4,651) | (2,137) | 0 | (3,493) |
| Group2Player | (10,332) | (11,426) | (18,828) | (8,491) | (19,326) | (4,840) | (5,909) | (5,544) | (12,515) | (9,931) | 0 | (9,740) |
| ShyPlayer | (6,721) | (4,790) | (8,296) | (4,886) | (2,557) | (2,036) | (4,385) | (305) | (7,357) | (4,752) | 0 | (4,190) |
| RainbowCastle | (15,626) | (12,459) | (18,523) | (10,104) | (31,795) | (11,235) | (8,458) | (12,571) | (13,206) | (16,893) | 0 | (13,715) |
| Group5Flood | 114,710 | 121,737 | 122,848 | 118,551 | 126,629 | 117,860 | 121,943 | 114,839 | 116,623 | 118,644 | 119,438 | N/A |
| Group6Player | (946) | (1,888) | (20,291) | (2,130) | (1,410) | (4,337) | (10,256) | (3,704) | (8,629) | (4,522) | 0 | (5,283) |
| [X=20, Y=20, p=0.001, q=0.002, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (400) | (110) | (129) | (120) | (201) | (110) | (111) | (111) | (110) | 30,729 | 30,729 | (156) |
| Group2Player | (27) | (293) | (36) | (127) | (111) | (28) | (179) | (502) | (46) | (38) | N/A | (139) |
| ShyPlayer | (308) | (248) | (215) | (365) | (285) | (1,044) | (182) | (237) | (4,622) | (285) | N/A | (779) |
| RainbowCastle | (210) | (192) | (227) | (409) | (1,040) | (264) | (173) | (3,047) | (173) | (347) | N/A | (608) |
| Group5Flood | (119) | (119) | (119) | (223) | (119) | (119) | (119) | (119) | (119) | (119) | N/A | (129) |
| Group6Player | 8,095 | 8,776 | 6,685 | 5,785 | (773) | (760) | 8,067 | (1,621) | (894) | (582) | 7,482 | (926) |
| [X=20, Y=20, p=0.005, q=0.01, maxrounds=50000] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (201) | (517) | (387) | (565) | (1,003) | (1,921) | (4,067) | (355) | (795) | (5,374) | 0 | (1,519) |
| Group2Player | (5,552) | 19,289 | (3,217) | (3,919) | (4,355) | (21,268) | (2,665) | (2,292) | (782) | 20,354 | 20,354 | (2,751) |
| ShyPlayer | (5,070) | (13,245) | (3,391) | (4,446) | (2,652) | (9,879) | (2,920) | (588) | (636) | (1,280) | 0 | (4,411) |
| RainbowCastle | (1,879) | (7,856) | 18,682 | 13,862 | 15,238 | (2,635) | 15,495 | 16,952 | 18,769 | (1,515) | 16,500 | (3,471) |
| Group5Flood | 12,229 | (3,434) | (1,850) | (489) | (3,426) | 13,689 | (3,863) | (497) | (4,465) | (1,478) | 12,959 | (2,438) |
| Group6Player | (1,481) | (4,883) | (1,400) | (1,966) | (2,129) | (1,061) | (3,198) | (1,393) | (558) | (664) | 0 | (1,873) |
| SECRET CONFIGURATIONS | ||||||||||||
| [X=20, Y=20, p=0.01, q=0.02, maxrounds=10000, K = 20] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (3,786) | (2,381) | (3,435) | (1,577) | (3,311) | (2,256) | (5,246) | (1,473) | (1,919) | (868) | 0 | (2,625) |
| Group2Player | (2,649) | (5,105) | (7,059) | (7,173) | (11,103) | (8,184) | (8,122) | (3,073) | (5,598) | (4,586) | 0 | (6,265) |
| ShyPlayer | (1,683) | (2,411) | (3,216) | (1,745) | (1,153) | (1,582) | (11,948) | (1,261) | (1,376) | (1,395) | 0 | (2,777) |
| RainbowCastle | (5,331) | 32,001 | 29,179 | 29,481 | 29,392 | 30,190 | 30,111 | (3,075) | 29,276 | (5,775) | 29,947 | (4,727) |
| Group5Flood | 19,666 | (8,870) | (8,771) | (3,389) | (1,670) | (2,090) | (2,024) | 18,873 | (2,009) | 18,556 | 19,032 | (4,118) |
| Group6Player | (1,615) | (1,274) | (9,824) | (1,710) | (2,690) | (2,089) | (392) | (2,401) | (831) | (1,372) | 0 | (2,420) |
| [X=20, Y=20, p=0.01, q=0.02, maxrounds=10000, M = 250] | Sim1 | Sim2 | Sim3 | Sim4 | Sim5 | Sim6 | Sim7 | Sim8 | Sim9 | Sim10 | Average End Energy | Average Extinction |
| Group1PlayerNew | (442) | (983) | (176) | (648) | (334) | (463) | (194) | (726) | (84) | (1,537) | 0 | (508) |
| Group2Player | (524) | (1,727) | (1,975) | (1,001) | (3,373) | (3,258) | (4,822) | (1,733) | (3,177) | (2,895) | 0 | (2,226) |
| ShyPlayer | (1,259) | (248) | (1,409) | (410) | (979) | (684) | (1,433) | (1,034) | (323) | (3,239) | 0 | (1,002) |
| RainbowCastle | 12,898 | (43,431) | 11,980 | 12,938 | 12,281 | 11,931 | 12,259 | 11,824 | 12,249 | 12,532 | 12,321 | (43,431) |
| Group5Flood | (933) | (1,069) | (1,672) | (1,222) | (666) | (3,031) | (2,296) | (882) | (3,527) | (3,711) | 0 | (1,069) |
| Group6Player | (504) | 31,558 | (1,443) | (194) | (36,273) | (1,010) | (1,615) | (1,205) | (957) | (408) | 31,558 | (1,205) |
Subscribe to:
Posts (Atom)