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:04]
ackley [Q: How to change the size of the MFM simulator?]
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? ====
 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? 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?
  
-A: The regular ​mfms has a super-duper ​new feature: You can specify the grid size+A: In version 3, the ''​mfms''​ simulator ​has a nice new feature: You can specify the grid size
 (and even the tile size!) on the command line. (and even the tile size!) on the command line.
  
Line 164: Line 255:
   you@linux$ ..path../​mfms {1H1} -flags -what -ever   you@linux$ ..path../​mfms {1H1} -flags -what -ever
  
-------+==== 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? 
 + 
  
-**Thank you!** That's better than drawing ''​Walls''​ by hand. The right side is the resized MFM simulator by {2C2}. And the smaller simulator seems faster! 
  
-{{:dev:mfms_signalrequest_2.9.png?​nolink&​200 |}}{{:dev:mfms_resize.png?​nolink&​200 |}}+**A31-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 |}}
dev/questions_ulam.1433055889.txt.gz · Last modified: 2015/05/31 01:04 by ackley