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
Tuesday, October 29, 2013
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)