Robust-first Computing Wiki - dev

abstract_elements

anonymous@undisclosed.example.com (Anonymous) — Tue, 23 Sep 2014 19:35:39 +0000

@@ -29,20 +29,21 @@
    SPoint wanderPt;
    Random& rand = window.GetRandom();
    MDist<R> md = MDist<R>::get();
    Dir d = (Dir)rand.Create(Dirs::DIR_COUNT);
-   u32 maxWanderDist = Dirs::IsCorner(d) ? R : (R / 2);
-   
-   maxWanderDist = MAX(GetWanderDistance(), maxWanderDist);
  
    Dirs::FillDir(wanderPt, d);
  
-   wanderPt *= maxWanderDist;
+   wanderPt *= Dirs::IsCorner(d) ? (GetWanderDistance() / 2) : GetWanderDistance();
  
-   if(window.GetRelativeAtom(wanderPt).GetType() ==
-      Element_Empty<CC>::THE_INSTANCE.GetType())
+   if(window.IsLiveSite(wanderPt))
    {
-     window.SwapAtoms(wanderPt, SPoint(0, 0));
+     if(window.GetRelativeAtom(wanderPt).GetType() ==
+        Element_Empty<CC>::THE_INSTANCE.GetType())
+        {
+          window.SwapAtoms(wanderPt, SPoint(0, 0));
+        }
+     }
    }
  }
  </code>
  Finally, we need a new pure abstract method. This will allow a sub-class to tell this base class how far it would like to wander per event. We write it like this, in a ''protected'' section:

atomic_parameters

anonymous@undisclosed.example.com (Anonymous) — Sun, 21 Sep 2014 17:54:05 +0000

@@ -21,15 +21,15 @@
  <code>
  typedef BitField<BitVector<BITS>, BYTE_BITS_LENGTH, BYTE_BITS_POSITION> AFByteBits;
  </code>
  
- make sure that BitField is included in the file by adding.
+ make sure that BitField is included in the file by adding:
  
  <code>
  #include "BitField.h"
  </code>
  
- to the top of the file
+ to the top of the file.
  
  ===== Make Getter and Setter =====
  
  We now need methods which access these bits. In the public section of your elemenet, place:
@@ -39,9 +39,9 @@
  {
      return AFByteBits::Read(this->GetBits(us));
  }
  
- void SetByteBits(const T& us, u32 bits) const
+ void SetByteBits(T& us, u32 bits) const
  {
      AFByteBits::Write(this->GetBits(us), bits & 0xff);
  }
  </code>

circular_dependencies

anonymous@undisclosed.example.com (Anonymous) — Mon, 22 Sep 2014 18:45:51 +0000

@@ -1 +1,43 @@
+ ====== Avoiding Circular Dependencies ======
  
+ Many times, you may run into a circular dependency when writing your Elements. This happens when you have two Elements, **A** and **B**, where **A**'s Behavior method needs to use **B**, and **B**'s Behavior method needs to use **A**. **g++** won't allow you to compile code like this witout defining these methods in a certain way. This tutorial will guide you through creating Elements like this.
+ 
+ In the repo, there are two Elements named **Element_CheckerForkBlue** and **Element_CheckerForkRed**, which were created to illustrate the correct way to get around this problem. Please use these as a reference when reading this tutorial.
+ 
+ ===== Create **.tcc** files =====
+ 
+ Each Element involved in this kind of problem needs an associated **.tcc** file, which is used to define its behavior. Create one of these files per Element in the **elements/include** directory.
+ 
+ After these are created, we need to attach them to the existing **.h** files. Just outside of the MFM namespace block, **#include** the corresponding **.tcc** file. For instance, in **A.h**, you need to **#include "A.tcc"** .
+ 
+ ===== Include dependencies =====
+ 
+ In each **.tcc** file, we can now **#include** the Elements that we wish to reference in our behavior function. For instance, in **A.tcc**, we need to **#include "B.h"** .
+ 
+ ===== Move Behavior method =====
+ 
+ Now, we need to move the Behavior method to our new **.tcc** file. Then, following the **A** example, write:
+ 
+ <code>
+ namespace MFM
+ {
+   template <class CC>
+   void Element_A<CC>::Behavior(EventWindow& window) const
+   {
+      /* Define Behavior for Element_A here. */
+   }
+ }
+ </code>
+ 
+ Then, in our **.h** file, we need to change the definition of our Behavior method to a prototype. Simply get rid of the body of the Behavior method and place a semicolon at the end of the line, like this:
+ 
+ <code>
+ virtual void Behavior(EventWindow<CC>& window) const;
+ </code>
+ 
+ Once you do this for both elements, they should now be able to reference each other and compile.
+ 
+ ===== Tips =====
+ 
+   * Make sure your **.h** file does **NOT** **#include** the Element which causes the circular dependency. Only your **.tcc** should do this.
+   * Your Behavior method might not be the only one with a circular dependency like this. Make sure to define any other methods which do in your **.tcc** as well.

clone_from_github

anonymous@undisclosed.example.com (Anonymous) — Sat, 15 Jul 2017 13:32:13 +0000

@@ -20,9 +20,9 @@
  ===== Install needed packages =====
  These packages are described in more detail in the immediately following subsections, but here they are all in one command for convenience:
  
  <code>
- sudo apt-get install git g++ libsdl1.2-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev libcrypt-openssl-bignum-perl libcrypt-openssl-rsa-perl libcapture-tiny-perl
+ sudo apt-get install git g++ libsdl1.2-dev libsdl-image1.2-dev libsdl-ttf2.0-dev libcrypt-openssl-bignum-perl libcrypt-openssl-rsa-perl libcapture-tiny-perl
  </code>
  
  ==== Install git ====
  
@@ -48,19 +48,16 @@
  
  ''libsdl1.2-dev'' is the package for the main SDL system.
  
  ''libsdl-image1.2-dev'' is the package for translating image types other than bitmaps.
- 
- ''libsdl-mixer1.2-dev'' is the package for playing audio.
  
  ''libsdl-ttf2.0-dev'' is the package for rendering TrueType fonts. Note that, despite the name, this is an SDL 1.2 package.
  
  Install the packages:
  
  <code>
  sudo apt-get install libsdl1.2-dev
  sudo apt-get install libsdl-image1.2-dev
- sudo apt-get install libsdl-mixer1.2-dev
  sudo apt-get install libsdl-ttf2.0-dev
  </code>
  
  ==== Install crypto support and misc packages ====

data_output

anonymous@undisclosed.example.com (Anonymous) — Fri, 17 Oct 2014 03:55:42 +0000

@@ -74,9 +74,9 @@
    Super::DoEpochEvents(grid, epochs, epochAEPS);
  }
  </code>
  
- Please note: There are 3 TODO tags in the above snippet. Make sure you modify the code to your needs before running.
+ Please note: There are 3 TODO tags in the above snippet. These are where you'll need to modify the code to suit your needs.
  
  ====AbstractDriver.h====
  Now we need to do a small modifcation to the AbstractDriver.h file. Paste the following code into the **public** section:
  <code cpp>
@@ -85,5 +85,5 @@
    return &m_simDirBasePath[0];
  }
  </code>
  
- And that's it! Happy sciencing.
+ And that's it! Happy scienceing.

element_tutorial

anonymous@undisclosed.example.com (Anonymous) — Wed, 17 Sep 2014 20:00:40 +0000

@@ -25,9 +25,9 @@
  
  In order for the compiler to be able to create a compiled version of this Element, you will need to create a small C++ file which associates with it. Create the file:
  
  <code>
- MFMv2/src/elements/src/Element_Creg.h
+ MFMv2/src/elements/src/Element_Creg.cpp
  </code>
  
  Add the line:
  
@@ -55,9 +55,9 @@
  
  <code>
  m_targetDensity(this, "density", "Target Density",
                        "The Creg will try to fill this many spots in its event "
-                       "window with other Creg.", 0, 3, 45, 1)
+                       "window with other Creg.", 0, 3, 41, 1)
  </code>
  
  The first argument is a pointer to this Element, which needs to be "this".

install_latest_mfm

anonymous@undisclosed.example.com (Anonymous) — Tue, 19 May 2015 03:54:37 +0000

@@ -5,12 +5,19 @@
  
  <code>
  git clone https://github.com/DaveAckley/MFM.git
  </code>
- After the clone is done, a new directory is created: /home/user/ＭＦＭ. The 'user' is your account name.
+ After the clone is done, a new directory is created: /home/user/MFM. The 'user' is your account name.
  
  ==== Install the MFM ====
  Now you can install the MFM. Go to the /home/user/MFM/. Type the make command.
  <code>
  make
  </code>
  If it throws out errors, there may be some dependencies lacked that caused these errors. Go to the  install SDL section of [[dev:clone_from_github|Clone from github]] to check these packages are installed. 
+ 
+ ==== check your MFM ====
+ Go to the /home/user/MFM/. Type the mfms command.
+ <code>
+ ./bin/mfms
+ </code>
+ The Movable Feast Machine should show up.

install_ulam

anonymous@undisclosed.example.com (Anonymous) — Tue, 02 Jun 2015 19:27:23 +0000

@@ -5,9 +5,9 @@
  
  You will need to clone the code from github. Git will create a new folder of ULAM, so you don't need to make a new directory.
  
  <code>
- git clone https://github.com/elenasa/ULAM.wiki.git
+ git clone https://github.com/elenasa/ULAM.git
  </code>
  After the clone is done, a new directory is created: /home/user/ULAM. The 'user' is your account name.
  
  ===== Configuration of the ULAM =====
@@ -25,7 +25,7 @@
  <code>
  make
  </code>
  If it throws out errors, there may be some missing dependencies. Open your package manager (for example, here we use Synaptic), and make sure you have installed libcapture-tiny-perl. {{ :dev:ulam_dependent_packages.png?560 |}}
- Once you get all the packages installed, try the make again. Welcome to ULAM. 
+ Once you get all the packages installed, try the make again. Welcome to the land of ULAM. This [[dev:program_ulam|portal]] will take you to a tour of ULAM programming.
+ 
  
- TODO: Next steps; where to now?

logging_and_debugging

anonymous@undisclosed.example.com (Anonymous) — Sun, 28 Sep 2014 11:34:05 +0000

@@ -2,9 +2,9 @@
  
  Here are a few quick notes on getting logging output from the simulator.
  
    * The simulator has a logging system accessed via the static object ''LOG''.
-   * The logging system has a 'level' determining how much output is desired.  The level can be set on the command line by the ''-l NUM'' switch, where ''NUM'' can range from 0 (for the least output) to 8 (for the most output).
+   * The logging system has a 'level' determining how much output is desired.  The level can be set on the command line by the ''-l NUM'' switch, where ''NUM'' can range from 0 to 8.  ''-l 0'' on the command line produces the least output, ''-l 8'' produces the most.
    * The logging levels have names and numbers: NONE(0), ERROR(1), WARNING(2), MESSAGE(3), DEBUG(4), DEBUG1(5), DEBUG2(6), DEBUG3(7), and ALL(8). 
    * The logging code provides direct methods for producing output at levels ERROR, WARNING, MESSAGE, and DEBUG.  For example: <code cpp>LOG.Debug("Hi there");</code> prints 'Hi there' to the console and the logging buffer (whose display is toggled by 'l' in the GUI) -- **if** the logging level is 4 or larger.
    * ''LOG'' offers simple, internally-implemented 'printf-like' functionality.  Among other things, it supports '%d', '%o', '%x', '%s'. Its biggest current limitation is no floating point support (so, no '%f', '%e', or '%g' conversions).  For example: 
  <code cpp>
@@ -21,6 +21,6 @@
  </code>
  might print something like ''20140928032150-3123: At (14,3): type is 00F0 (so there)''
  if the logging level was 3 or higher.
    * Note the logger adds a newline at the end of each log message, so typically it's expected that each log message will be a single line.
-   * Use %d for both signed and unsigned ints; there is no '%u'.
-   * Grep around in the codebase for examples!
+   * Use %d for both signed and unsigned ints; there is no '%u'.  (Or use %x or %o).
+   * Grep around in the codebase for 'LOG' to find lots of examples!

plotting_elem_counts

anonymous@undisclosed.example.com (Anonymous) — Sun, 26 Oct 2014 21:01:56 +0000

@@ -1,16 +1,17 @@
- The //plot_element_counts.py// script.
+ The //plot_element_counts.py// script.  If you get an error that it cannot find the module "matplotlib" or something, it's probably not installed.  This fixes that on Ubuntu:
+ 
+ sudo apt-get install python-matplotlib
  
  Example usage:
  
  ./plot_element_counts.py /tmp/xxx/tbd/data.dat "a nice title" "Data" "Creg" "Dreg"
  
  <code python>
  #!/usr/bin/env python
  
- # Reads .mfs files in a directory and makes plots of
- # particular elements (Data, Isolator) in them
- # Work-in-progress.
+ # This script plots the counts of the specified elements against AEPS, 
+ # each plot having the specified title.
  
  import sys
  import matplotlib.pyplot as plt

program_ulam

anonymous@undisclosed.example.com (Anonymous) — Thu, 14 Jan 2016 07:13:08 +0000

@@ -19,11 +19,14 @@
  
  
  ==== EventWindow Indices ====
  
- The following graph shows the index numbers within an ''EventWindow''. The ''EventWindow'' has two functions to describe those indices. The ''getCoord(siteNum)'' converts an 1-d index(which is an ''Unsigned(6)'' ) to a 2-d coordinate(which is a quark ''C2D''). The ''getSiteNumber(coord)'' convert ''C2D'' back to 1-d ''Unsigned(6)''.  The quark ''C2D'' has ''getX()'' and ''getY()'' to interpret the //(x,y)// better.
+ {{ :dev:event-window-10.png?300|}} The image at right (click to enlarge) shows the indexing scheme used for sites within an ''EventWindow''.  Both 2D 'coord' numbering and a 1D 'site number' approach are offered.  
+ 
+ The ''getCoord(siteNum)'' function converts an 1D index (which is an ''Unsigned(6)'' ) to a 2D coordinate (which is a quark ''C2D''). The ''getSiteNumber(coord)'' convert ''C2D'' back to 1-d ''Unsigned(6)''.  The quark ''C2D'' has ''getX()'' and ''getY()'' methods to access the //x// and //y// coordinate values individually.
+ 
+ In general, when code is referring to individual fixed sites within the event window, the 1D coordinate system is used (see the 'First' element below for an example).  Two-dimensional C2D indexing is more commonly used when there is some flexibility depending on geometry or relative positions.  
  
- {{:dev:event-window-10.png?280|}}
  
  ===== The 'First' Element =====
  
  Our first ULAM element is literally named ''First'', and is stored in a file called //First.ulam//: 
@@ -31,9 +34,9 @@
  <code - First.ulam>
  element First{
    EventWindow ew;
    Void behave(){
-     ew[1]=ew[0];
+     ew[1]=ew[0]; // Copy self one site west
    }
  }
  </code>

questions_ulam

anonymous@undisclosed.example.com (Anonymous) — Mon, 01 Jun 2015 18:11:20 +0000

@@ -143,9 +143,100 @@
  
  ==== Q: Does ws.getPick(typeIndex) only return one site? How to access each site within an event window? ====
  **Thank you**! Now I understand that ''ws.getPick(typeIndex)'' returns an event window index. ''ws.getPick(typeIndex)'' can randomly pick one atom of this type. When I want to select an atom of this type but also has the maximum value of a certain data member, I should use the for loop to check each atom of this type and get this maximum atom. Like here I want to find the ''Request ATOM'' which has the max density value within this EventWindow. 
  
- **A: 31-May-2015 12:51:43AM-0600:** To select an atom based on anything other than its type, ''WindowServices'' can help with the event window indexing, but in general you'll need to write a loop explicitly, rather than using ''scan()''.  But even if so there's some help for doing fair picking among maxima and minima.  (Rest of answer pending!) 
+ **A: 31-May-2015 12:51:43AM-0600:** To select an atom based on anything other than its type, in general you'll need to write a loop explicitly, rather than using ''scan()'' -- although ''WindowServices'' can help with the event window indexing.
+ 
+ But even when you do need to loop, we have ''SelectorServices'' to provide some help for simpler tasks like finding and picking fairly among maxima and minima.  Here are two ''SelectorServices'' examples.  The first, ''SSDemo1'', uses ''SelectorServices'' in a relatively general way, while the second, ''SSDemo2'', is a bit optimized for shorter code.
+ 
+ <code - SSDemo1.ulam>
+ 
+ /**
+    SSDemo1s share the highest Score among their connected group.
+  */
+ 
+ element SSDemo1 {
+   // Typedefs
+   typedef Unsigned(8) Score;
+ 
+   // Utilities
+   EventWindow ew;
+   Random random;
+   DebugUtils du;
+ 
+   // Data members
+   Score val;
+ 
+   Void behave() {
+     if (val == 0) // randomize initial vals
+       val = random.bits(val.sizeof);
+ 
+     WindowServices ws;    // Scanning support
+     SelectorServices ss;  // Selection support
+ 
+     ws.reset(1,4); // Scan all but us (for this example)
+     ss.reset();
+ 
+     for (Int idx = ws.next(); idx >= 0; idx = ws.next()) {
+       Atom a = ew[idx];
+       if (a as SSDemo1)
+         ss.maximize(idx, (Int) a.val);
+     }
+     // This code is fairly general, but cumbersome.  Compare SSDemo2
+     if (ss.selectionMade()) {
+       Int sidx = ss.getSelectedKey(); // The site that maximized
+       SSDemo1 f = (SSDemo1) ew[sidx]; // which we know is a SSDemo1
+       if (f.val > 0)                  // ..if they've been initted
+         val = f.val;                  // ..pick up their val
+       du.printContext();              // and report for debugging.
+     }
+   }
+ }
+ 
+ </code>
+ 
+ <code - SSDemo2.ulam>
+ 
+ /**
+    SSDemo2s share the highest Score among their connected group.
+  */
+ 
+ element SSDemo2 {
+   // Typedefs
+   typedef Unsigned(8) Score;
+ 
+   // Utilities
+   EventWindow ew;
+   Random random;
+   DebugUtils du;
+ 
+   // Data members
+   Score val;
+ 
+   Void behave() {
+     if (val == 0) // randomize initial vals
+       val = random.bits(val.sizeof);
+ 
+     WindowServices ws;    // Scanning support
+     SelectorServices ss;  // Selection support
+ 
+     ws.reset(0,4); // Scan everyone including us
+     ss.reset();
+ 
+     for (Int idx = ws.next(); idx >= 0; idx = ws.next()) {
+       Atom a = ew[idx];
+       if (a as SSDemo2)
+         ss.maximize((Int) a.val);  // Don't need the idx this way..
+     }
+     // We scanned ourselves, so we know ss.selectionMade() will be
+     // true.  So we just take the chosen value (even if it was ours).
+     val = (Score) ss.getSelectedValue();
+     du.printContext();
+   }
+ }
+ 
+ </code>
+ 
  
  ==== Q: How to change the size of the MFM simulator? ====
  Sometimes the canvas is too big for my experiment. If I don't want those atoms diffuse too far away, I will draw a box of ''Wall''. Can we change the size of MFM simulator?
  
@@ -166,9 +257,12 @@
  ==== Q: Do smaller grid geometries make the simulator run faster? ====
  
  **Thank you!** That's better than drawing ''Walls'' by hand. The right side is the resized MFM simulator by {2C2}. And isn't the smaller simulator running faster?
  
- {{:dev:mfms_signalrequest_2.9.png?nolink&400 |}}{{:dev:mfms_resize.png?nolink&400 |}}
+ 
+ 
  
  **A: 31-May-2015 01:06:01AM-0600: ** It depends somewhat on your hardware -- in particular, how many //real// cores you have, but yes, in general a smaller grid geometry -- fewer and smaller tiles, down to some limit -- will typically be faster than more and larger tiles.  Any single tile geometry will be running single-threaded, though, so in some cases multiple smaller tiles will be faster than one bigger one -- you'll need to experiment some, if maximizing AER is crucial.   Also, if you type **''a''** a few times after typing **''i''** in the simulator, it will display the AER it is producing, so you can get a rough sense of what's faster and slower.
  
  On a separate point, note that the "edge of the grid" is somewhat different that a ring of ''Wall''s.  For example, non-existent sites return ''false'' from the ''EventWindow isLive'' method, but sites containing ''Wall''s return true.  For consistency you might want to draw a ring of ''Wall'' around the boundary of even a smaller grid.
+ 
+ {{:dev:mfms_signalrequest_2.9.png?nolink&400 |}}{{:dev:mfms_resize.png?nolink&400 |}}

quiz_ulam

anonymous@undisclosed.example.com (Anonymous) — Sun, 28 Jun 2015 17:52:40 +0000

@@ -84,9 +84,11 @@
  In the bigger simulator and less time length, we had no data hitting the boundary. The ''{4C4}'' average distance we got seems greater than the ''{2C2}'' average distance. However, nearly 1/4 of the ''{2C2}'' data fell out of the edge. So the actual average distance in ''{2C2}'' should be greater than the data shows. In both experiments, we can see the grid helped to extend the range a ''Pair'' traversed. The extension in ''{2C2}'' seems to be less than 5% (from 18.8 to 19.4) because more data points fell out of the edge. In ''{4C4}'' experiments, the average distances are extended nearly by 9% (from 21.1 to 23.1). This shows that the some //pulses// that travel faster than //walks// are produced in the grid. 
  
  The end-positions of the experiments didn't show obvious bias. That's fair because of the initial layout of our experiments. When ''Boxes'' are evenly placed in grid pattern, they //attract// the ''Pairs'' evenly, which will produce no bias. When ''Boxes'' are placed in a line, they are too sparse to //trap// ''Pairs''. This did not produce bias either. In the following experiment, we will place a bunch of ''Boxes'' in the 1st quadrant. This cluster of ''Boxes'' will //attract// the first ''Pair'' and produce more ''Pairs''. Then, the end-positions will show obvious favor to the 1st quadrant.                      
  
- If the end-positions of ''Pairs'' are not surprising, how about the ''Boxes''? Did they still remain in line or in grid? How are they messed up by the ''Pair''?
+ {{:dev:4overlay_500.png?350|}}
+ 
+ The above graph is what we saw if we put the three pictures together. If the end-positions of ''Pairs'' are not surprising, how about the ''Boxes''? Did they still remain in line or in grid? How they were messed up by the ''Pair''?
  
   
  Excluding runs that hit the boundary messes up the data.  Should use a bigger grid, so that hitting the boundary is very rare.  It will run slower but just use more machines.  And we don't care if more pairs are created, right?  We just wanted the distance to the farthest pair.