From: thunk Date: 2010-03-22T08:35:09+09:00 Subject: A humble start on a Boid System Vocabulary - I just took a crisp spring bike ride to our coast guard station and spent the whole ride thinking about these Boids again. I've been working with them solid for months and somethings that have gradually become clear to me as I have seen things begin to work, and as they have evolved are not so easy to communicate about. Explaining these things separately probably does not do justice to the strong model that is a nice part of the advantages of this design/architecture. Working with Boids is rather like using OO, at first it seems to be a lot of fuss about nothing, then when you've used inheritance and all you can't even think how you'd do it another way. While I'm not saying at all, that is design has anything like the significance of OO I have come to be convinced that there are some big niche projects to be done in this style for reasons I hope to help make clearer. For example there is a concept of "categorization" where the Boid author is given a series of simple choices about what his Boid is about. Seems simple, maybe even stupid? Let the author give some "tag", right? Well let 5,000 lines of text zipl past you telling you what Boid is making what assertion and the status and the messages and all you want to know is "how many hits" did I get on "contraindications on drug xyzarin" then the lights go on and you see the need for a "scoreboard". Well if all you have are dumb tags how can you "keep score" - ahhh - and now the expert is presented with a series of choices representing a Matrix - and now you can change colors and do the cool stuff web design stuff. I used Wee and came up with a Panel that also supports Drill down, and since the Boids keep really intricate records I've allowed for 3 levels from summary to totally_anal. So if I'm going to communicate about this, there is some sort of need for a vocabulary that fits this way of thinking... and on my ride I remembered that GitHub folks had their "Porcelain" and "Plumbing" that was very amusing and useful so why can't Boid Folks have "Satz" and "Swarms" and and such - so here are the terms off the top of my mind in no particular order and if there is interest any interest in this we can refine it further: BOID Several types - makes assertions or can be a review, or can contribute to reports. Several SECTIONS- Headings, Attributes, Assertions,Messages, Conclusion each a DSL. More coming. ScrptRec - sort of the "black box" a recording of everything and anything that happens to the Boid that can be of interest - names of author, intermediate calculation results, everything gets recorded into this object. Nothing else is left when the Boid is finished. SWARM A logical set of Boids. SwarmSession the mother of all swarmsObjects. Fire! The "living" part of the Boid cycle. All "Assertion" type boids use at least one "helper_class". Data is held READY in the Screens - and what they are is domain dependent but this is where simulation is coming in for me - I use a real Drug ClassBase but simulate "patient records" by the 1000's for testing. I'm not sure if this is particular strength of Boid Architecture or not. ....All 5 sections are executed in order, each part tends to be just a few lines. Each section has a specific DSL to handle it (thank you Ruby!!) begin Core "flight time" Swarm Objects ===================== SwarmSender Loads the Boids, sequences them by "pass numbers" and so forth - think of those wwII pacific war movies and aircraft carriers if it helps - and wear a white scarf. | | | | | | v v v SwarmReader Literally "debriefs" the Boids one at a time as they come back to the carrier (if you liked that analogy). Scores are tabulated for the "control panel" so colors can change with the "hits". The Blackbox is offloaded and stuck away for analysis - and it is ALL there - a beautiful thing if you really want to drill down on how a result was arrived at. I have implemented 3 levels of Drill down, with the 1st level being a summary and so on. But so you know, every attribute used in every assertion has been recorded. See Categorization / ControlPanel =============== Screens ..... Between the Sender and the Reader (conceptually) there is at least one "screen" but two is much more interesting. These are what the Boids "see" and use "to load their attributes" and "fire!" on them. Helper_Classes ,,,,,,I was using this before checking out Ruleby, honest, but I see those folks had the same concept, I think. Anyway it takes the load off the Boids and really helps make the 'Expert Session' almost trivial and that seems important / critical to the outsider contributions aspect of all this. A few clues: The names of the Helper Library is the first choice the the Assertions, then all the '?' methods are listed to the Expert. These methods must (so far) result in a true/false or fail response and all this stuff is inherited anyway. helper_classes can have access to all kinds of resources. .....Once a domain is established this is where the "programming goes" - expanding existing, creating new libraries. See expert session - they are tied to this WebApp. ================================ End "flight time" core Boid Class descriptions Expert Session - ......This is everything and anything needed by an "outsider" to author a new Boid. The Boid type is selected, then there is a screen for each "Section" of the Boid. Heading -> Attributes -> Assertions, Messages, Conclusion - nothing complicated, the messages are the "meat" because they explain what the author is up to. There's categorization. .....I had this on-line for a different domain written in Wee (thanks to Michael Neumann) and it was possible to turn, probably the most "exotic" part of this thing, the Assertions, into an exercise in selecting method names (all '?'s methods) and little more. ....What I'm messing with right now is a "super boid" that can multiply itself. Some of this is domain specific. There are "system" boids that can kick everything off, and clean up after.... and on it goes. After awhile, its like OO and you can't even think about how this would be done any other way. Its common sense and fun. ------------------------------------------------------ not really 'core' to the Boid System ClassBase It ain't yo daddy's db - whatever else it is - one "record" might correspond to one class? Not sure anymore, I can't think that way, but one interesting thing is that at the Method level I have "standardized' on always returning an Array of "Satz" (from German for sentence) - and this thing is a Hash that follows certain DSL like rules. A satz can be used for quick computer access but it can also be converted to a natural language, Well almost :). Every satz has uses several types of Keywords, :NOTES are useful for letting humans know understand if things getting confusing, and ends with a :REF to keep everything straight. ....I would not mention this class but it really warps nicely into my Boid based design. The "techno-english" sentences derived from the Satz are easier to understand and less ambiguous than English - I have not been able to get myself to remove the Brackets around the logic because it seems clearer to me. Not sure what other folks are going to think. Here are a few examples: IF... [ CONDITION *is* CHOLESTEROL (HIGH) ] THEN... this is a CONTRAINDICATION* *Jenike MA Editorial. Journal of Geriatric blabla.... IF... [ CONDITION *is* KNOWN ALLERGY ] THEN... this is a CONTRAINDICATION * *Syzju G. Igta T, Effects of blabla ============================== Here's an example summary - as things are running now on my 3 yo Hackintosh Number of Boids Fired: 60 BOID Execution Time: 0.02725100517 Seconds Number of Boids: 60 Nr of Boids Fired: 51 Time per Boid: 0.000454183419545492 Fired per Second: 2202