people:andres_ruiz:project
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
people:andres_ruiz:project [2014/10/13 19:44] – afruizc | people:andres_ruiz:project [2014/12/09 06:07] (current) – afruizc | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | A very short presentation can be found [[http://slides.com/andresfeliperuiz/achieving-global-communcation]]. | + | Final link of download: |
- | ===== Importance Of Communication: ===== | + | ==Graphs:== |
- | The importance of communication has been discussed in class before, but essentially it comes down to three points: | + | {{:people: |
- | * Spacial translation of entities composed by more than one element. | + | {{: |
- | * Achieving of global objectives that are otherwise not possible without communication. | + | {{: |
- | * The development | + | == Final DRAFT of the paper: == |
+ | http:// | ||
- | ===== Design of the protocol: ===== | + | == Abstract: == |
- | {{: | + | In the Movable Feast Machine, direct interaction is limited to small regions of space, but many computations could benefit from larger scale structure. This paper presents a simple aggregation and localization strategy allowing individuals to form communicating groups and find their own absolute positions within the group |
- | I have explored two different options so far. The one involving a third party seems more promising. | + | == Model Description: |
+ | Figure 1: [[http://cs.unm.edu/ | ||
- | __TP protocol (Third Party protocol): | + | In order to understand |
- | The protocol incorporates a new element called | + | The density |
- | The protocol is based on states. This means that every atom should be in one state, and such state determines what it is that the atom should be doing. The states can have external inputs, | + | The state of an element |
- | The protocol | + | The attractor state is the state in which an ASDF element moves elements |
- | === Advantages: === | + | There is a two stage process that will successfully achieve the desire result of localization of each one of the elements inside their blob. |
- | * Modularity. | + | These self-organization and localization stages are roughly described in section 3.1, and are given a more thorough treatment in section 3.2. |
- | * Abstraction. | + | |
- | * Simplification of design. | + | |
- | === Limitations: | + | Section 3.1: Model Overview. |
- | * Overlapping states. | + | |
- | * Not unlimited behavior. | + | |
- | ===== Concreteness | + | As mentioned earlier, the ASDF elements will self-assemble in different blobs that will then start their localization process based on where they consider their global position |
- | Illustrate | + | |
- | So far I have almost finished | + | We now briefly describe what an Event in the MfM architecture is because this will provide us with a useful framework to describe the behavior of the ASDF element in both, the organization and the localization stage. In its most essential case, an event is the means by which the mfm tells an atom that it is their turn to wake up, interact with the environment, |
+ | |||
+ | Section 3.2. Model detailed description | ||
+ | |||
+ | We now give all the details on how both stages of the operations | ||
+ | |||
+ | Section 3.2.1: Self-organization process | ||
+ | |||
+ | The self-organization process | ||
+ | |||
+ | Algorithm 1: | ||
+ | |||
+ | function self_organization(): | ||
+ | if (I become attractor): | ||
+ | A[] = empty elements in ew. | ||
+ | B[] = ASDF elements in ew. | ||
+ | i = j = 0 | ||
+ | while (empty_spots && elements_to_relocate): | ||
+ | change pos of element B[i] to A[j] | ||
+ | turn B[i] into attractor | ||
+ | increment i and j | ||
+ | |||
+ | In words, what the self-organizing procedure does is: at the beginning of an event, every element has some chances of becoming an attractor, if it turns out that the element does not become an attractor, the normal execution of the behavior function will continue; if on the contrary, the element does become an attractor, then it will gather information from it’s event window, this information includes all the elements that are empty, starting from radius 1 to radius 4, and other ADSF elements starting from radius 4 to radius 1. These two orderings of operations are important because they allow for the elements stay as close as “possible”. After having these two pieces of data, the element will start allocating the ASDF elements that were found on the outer layers into the inner layers | ||
+ | |||
+ | After this step is done some more work has to be done in the density blahh.. | ||
+ | |||
+ | Section 3.2.2: Localization process | ||
+ | |||
+ | In order to carry out the Localization Process (locp from now on), it is important to have the elements as close together as possible, or at least, as least spread as possible, because this will provide | ||
+ | |||
+ | This second stage assumes that, in addition to determining whether an element is an attractor or not, the elements have to have some state stored in them. Each ASDF element has four counters | ||
+ | |||
+ | Algorithm 2 | ||
+ | |||
+ | function self_organization(): | ||
+ | if (has_converged? | ||
+ | if (this should check again): | ||
+ | if (! has_converged? | ||
+ | set convergence flag OFF | ||
+ | alert neighbors of discrepancy | ||
+ | else: | ||
+ | this.count_north = north_n.count_south + 1 | ||
+ | this.count_south = north_n.count_north + 1 | ||
+ | this.count_east | ||
+ | this.count_west | ||
+ | # Now for each direction check the two directions | ||
+ | # orthogonal to it in order to determine convergence | ||
+ | # and to fix discrepancies. | ||
+ | |||
+ | # For north I should then check east and west and | ||
+ | # compare my north counter with them. | ||
+ | this.count_north = max(this.count_north, | ||
+ | |||
+ | # and perform this for the other three counts. | ||
+ | # after all has been done, check for convergence. | ||
+ | if (has_converged? | ||
+ | set convergence flag ON | ||
+ | |||
+ | |||
+ | The locp can get confusing, which is why we will try to cover all the caveats that it brings along. It is helpful to look at figure 1 and understand this as a converge process, meaning all the elements in a blob will eventually have a correct value on each one of their counters, however throughout different iterations | ||
+ | |||
+ | Think about the best way to explain the crap out of this! | ||
- | ===== Todo list: ===== | ||
- | * Make the Organizer element much more smarter: | ||
- | * Tell the ASDF elements to go to a place such that the distance traveled is partially minimized. | ||
- | * Move in a way that Organizer' | ||
- | * Think up the experiment that will determine the complexity. |
people/andres_ruiz/project.1413229470.txt.gz · Last modified: 2014/10/13 19:44 by afruizc