User Tools

Site Tools


dev:questions_ulam

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dev:questions_ulam [2015/05/31 01:22]
ackley [Q: Do smaller grid geometries make the simulator run faster?]
dev:questions_ulam [2015/06/01 12:11] (current)
xychen [Q: Do smaller grid geometries make the simulator run faster?]
Line 145: Line 145:
 **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. ​ **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'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(8Score; 
 + 
 +  // 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? ==== ==== Q: How to change the size of the MFM simulator? ====
Line 168: Line 259:
 **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? **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. **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. 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 |}}
dev/questions_ulam.1433056944.txt.gz · Last modified: 2015/05/31 01:22 by ackley