A Simple Discrete-Event Simulation: Part 33

Posted on October 31, 2016 by R.P. Churchill

My main motivation for trying to break the current functionality into M, V, and C layers isn’t about purity of design pattern so much as getting a lot of unnecessary overhead out of the simulation components themselves. They shouldn’t contain any less support functionality than they need, but they shouldn’t include any more, either.

Looking at the output and code for, say, the Queue component, shows that a lot of what’s going on inside the component itself is merely in support of the status display and timing mechanisms. I’m thinking that as much of that as possible should be moved outside of the component object itself.

If all of the display overhead were removed from this code we’d be left with roughly this:

You can see that gets rid of most of the code, and even some of what is left is only there to draw status information in the lower, scrolling text area.

If we want to provide the deleted capability in a more streamlined, external way then we can identify some possible requirements:

  • As much initialization and signalling as possible should be external to the simulation elements.
  • As much state information as possible should be external to the simulation elements.
  • The updating and display of such information should be able to be suppressed (or reactivated) by setting a single, global variable.
  • The external display mechanism needs to maintain a link (pointer) to the simulation element so it knows where to get its data from.
  • The simulation element may need to be able to reference an external display element via a link (pointer) but it would be better if such a link were not necessary.
  • Some displays should be permanent and updatable.
    • Since the display is always visible once defined the simulation element may not need to do anything special to allow the external display mechanism to update itself.
    • If any information in the display mechanism is to “hide” itself on a timed basis then the timing mechanism should be handled entirely within the display mechanism.
  • Some displays should be temporary on a fire-and-forget basis.
    • The internal assignment or initiation of such a display should be kept to one line.
    • If a subsequent update should happen that would change the originally initialized display before it times out, the one-line call should be able to identify the correct external display mechanism and cause it to display the updated information instead.
    • The external display mechanism should incorporate its own timing and hiding capability, if appropriate.
  • Setters and getters need to be created for all internal properties whose values will need to be displayed.
  • Functions that do external update assignments of series of values may need to be defined externally.
  • Some design decisions will reference the fact that (for the time being) the entire display is redrawn after certain classes of events, namely ones that involve processing an event from the future events queue. This idea will have to be revisited when we reincorporate wait..until events and the current events queue.
  • Given the foregoing, it may be possible to detect certain classes of events outside of the simulation elements.
Posted in Simulation | Tagged | Leave a comment

Future Trends and Efforts in Education

Posted on October 27, 2016 by R.P. Churchill

I’m tabling the discrete-event simulation framework effort for today to provide a list of materials concerning the ongoing changes in the field of education. I compiled this list in order to share it with a few individuals over the past couple of months.

Many of the items are of interest to me because they involve automation and the universal and ongoing trend of continual improvements to providing the best resources at the best cost and with the highest degrees of personalization and feedback. As always, the point is not automation for automation’s sake, but to provide increasing value to people everywhere so they can develop and leverage their human potential to the greatest possible degree. Activities should be automated where that is the best use of resources, and human guidance and feedback should be employed where it adds the greatest value. Society can, should, and will continue to explore this process from all possible angles, even against resistance from some quarters.

Here is the list, without further comment:

In college I wrote an interactive (supposedly) artificial intelligence-based system to train student how to solve certain classes of engineering problems. This has inspired me to remain continually aware of developments in the fields of both AI and electronic / automated education systems since I did this work in 1983 and 1984. A longer description of the work is here.
—
Dr. Sugata Mitra’s Hole-In-The-Wall Project
His famous TED talk is here.
Mitra’s work illustrates that kids largely don’t need the overhead associated with traditional schooling.
—
Pauline Dixon has done a bunch of research on small, private schools all over the world, including in the poorest slums where conventional wisdom says such things cannot exist and cannot function effectively. Check her book.
An interesting interview is here.
—
James Tooley did similar work and has produced this moving book in the same vein.
—
John Taylor Gatto is a former New York State Teacher of the Year, largely denounced by the State of New York and right-thinking educators everywhere. Gatto eviscerates traditional public education (especially in New York City, but really everywhere). I especially recommend his books, Weapons of Mass Instruction and The Underground History of American Education. One of the things he emphasizes is getting students involved doing active things in the community rather than just sitting around passively soaking up information.
—
Praxis is an on-the-job apprenticeship program meant to replace traditional college education.
An interview with founder Zachary Slayback is here. Note the link to a book by him and several education-related links from the Tom Woods site.
T.K. Coleman is also associated with this effort.
A local (to D.C.) version of this is here.
—
From the Department of the Obvious:
Khan Academy
See also this, which is germane to any type of remote instruction and not just the Khan Academy. Also look into the concept of gamification in conjunction with these elements.
—
If I had kids I would be using (parts of) the Ron Paul Curriculum. The model is interesting and involves having the children teach themselves to the greatest degree possible from a fairly young age. That said, I would almost certainly get my science courses elsewhere, or handle them myself.
—
There are many online sources of training in every imaginable field. I have used a little bit of stuff at Code Academy but I love Udemy.com.
A friend of mine did well with The Learning Tree, which in many cases has the virtue of getting students together with other people as an aid to feedback and concentration.
—
Universities are putting all kinds of stuff online:
Coursera
MIT
Carnegie Mellon
Harvard
The elite schools and the big state schools will survive (possibly at lower cost). The third rate schools with fourth rate instructors are toast.
—
There are more dedicated (and expensive) models out there. For example, I got my Six Sigma training and certification through Villanova Online. This program includes discussion forums, online multiple choice tests, a proctored project, and weekly online lectures by the proctor — a little bit of everything.
—
This seems like more of the same, but I have no experience with it: Udacity
—
There are also a bunch of coding bootcamps out there, though their effectiveness is increasingly being called into question.

Posted in Economy and Society | Tagged , , , , | Leave a comment

A Simple Discrete-Event Simulation: Part 32

Posted on October 26, 2016 by R.P. Churchill

Before adding further complexity to the existing system (read: before adding the capabilities which will make it usable!) I wanted to back up and consider the internal architecture of what I’m building. The goal is something that conforms to the classic Model-View-Controller (MVC) pattern as shown in the figure.

So how does this manifest itself, exactly?

The model layer includes the mechanics that make the system work. There are aspects of this related to the underlying mechanics of the discrete-event system itself, the components that process the entities, and the entities that are processed. The mechanics concern not only how the system “works” but also how it saves and restores models and configurations and other functions. What we’ve created to this point is the discrete-event mechanisms, the components, and the entities, all at a fairly basic level. While there’s a lot more that can be done, conceptually we’ve already included everything we need to create working systems, or at least systems with hard-coded configurations.

Interestingly, the word “model” here has multiple meanings. In MVC parlance the “model” is the functional layer that does the simulation and system-level management. From the user’s point of view the “model” is the representation of an external system of interest that is built up from the various components, entities, and other elements which may be added.

The view layer includes the mechanics that let the user see what’s going on. So far we’ve created objects that display the state of the components, and that information displays the status of the entities indirectly. The data display objects are external to the components, and should be made even more external. These comprise one aspect of the view layer. Another aspect of the view layer will be a system of graphic representations that will be more directed to showing the configuration, connections, and operation of the modeled elements in a more intuitive way. The current setup is very abstract and takes some insight and concentration to follow. A more graphic- or animation-based representation will be easier to watch and understand. It will work the same way as the data display objects but will show the connections between components and the movement and location of the individual entities. Note that this layer is very helpful in understanding, developing, and debugging both the simulation layer (the MVC “model”) and each model’s configuration (the user “model”).

The view layer provides mechanisms to display the state not only the model’s components and entities but also the state of the system as a whole. Possible state information can include the load status of a user “model”, the viability of a user model, the execution time of the system during a run, the execution state of a system (running mode, paused, ended, initialized, outputs compiled and complete, and so on), user permissions, and other factors.

The viability of a user model has to do with its completeness and internal consistency with respect to being able to run, which has to do with any automated verification which can be performed. This is different than a model’s accuracy or suitability with respect to the external system of interest; that requires validation, a process which is difficult to impossible to automate.

The control layer includes the mechanics that let the user control what’s going on. This means controlling the definition, construction, modification, and maintenance of the models as well and the execution, interactions, and outputs from the model. As always, there are aspects of this related to the individual component types, the entity types, and the underlying mechanics of the system. The controls are accessed through the view layer (for example, by right-clicking on a graphic representation of a component or entity) and allow the user to perform CRUD operations on the user “model” elements as well as at the system “model” level.

The MVC pattern usually implies something about how the implementation is accomplished. It could be that the implementations at each layer are highly separated, so that items in each layer are as independent as possible. It could be that items at a lower level don’t have to contain any hooks at all that would allow them to be manipulated by items at a higher level. In practice there are bound to be some hooks, and the question then becomes the form the hooks and connections actually take. Going to the other extreme it might also be possible to construct objects for each component and entity type that provides the functions needed by each layer. That is, each component or entity could contain all of the mechanics it needs to provide functionality at the model, view, and control layer.

There are reasons to go either way and it could be argued that leaning toward horizontal slicing is preferable to tending toward vertical slicing for many reasons. However, design decisions will be made based on many factors, including execution speed, memory footprint, maintainability, modularity, and other considerations. I’m not always a stickler for purity on such issues in the end, but these kinds of problems always benefit from some conscious thought. It could be that the model-level items should be fairly independent but the view- and control-level items should be functionally combined. That seems to be the direction I’m headed.

Posted in Simulation | Tagged , , | Leave a comment

A Simple Discrete-Event Simulation: Part 31

Posted on October 25, 2016 by R.P. Churchill

Today I made a few basic changes.

Instead of placing all elements (components and entities) that contain discrete-event simulation features into the setOfEntities array I created a setOfComponents array and placed the components in there, instead. This allows me to loop through lists of like elements to perform certain operations on them, like asking them to draw themselves or (possibly) asking them to de-link themselves at the end of a simulation so they can be garbage collected.

I added a function to remove entities from the setOfEntities array when they finish getting processed at an ExitComponent.

Finally, I moved the definition of the detail parameters of the DataDisplay objects so they can be defined outside of each component.

Posted in Simulation | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 30

Posted on October 24, 2016 by R.P. Churchill

The Exit component is always available to accept any entities sent to it. It doesn’t have to store any entities but only has to keep track of when they “arrive,” which means they are leaving the model. The Exit component does calculate and report the residence time of the entity in the entire system, however.

I added reporting of residence time in the Queue component, which can vary, and the Process component, which is currently always a fixed value. I also modified the order of operations just a hair so the reporting operations go in the order that makes the most sense.

(Click on the “Step” button to advance through the model, refresh the page to run it again.)

Here’s the code for the Exit component.

Now we have a working representation of the basic components of the kind of systems I’ve often worked with. There are a ton of things that could be done going forward, so we’ll work them in each day going forward.

Posted in Simulation | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 29

Posted on October 20, 2016 by R.P. Churchill

Today I added a Process component. This component is meant to represent a process that takes some amount of time to complete. The time could be zero and there can be other side effects, which usually involve changing properties of the entities being processed, but the time consumed is almost always the salient feature.

The Process component works almost exactly like the Queue component, including the incorporation of the internal array that can hold multiple entities. I don’t do anything special with this yet, but this capability is in place to support special processes of which I’m aware (e.g., a stacked booth where entity A enters first, followed by entity B, and where their process times are independent; if A finishes first it can leave right away but if B finishes first it has to wait for A). For the current implementation the Process component can work with only a single entity at a time.

I also modified the handoff of entities between components. When an entity gets to the far end of a Queue component (which happens instantaneously at present), it queries the next component (the Process component) to see if it can accept an entity. If it can then the entity is passed downstream. If it cannot then nothing happens. On the other end, the downstream component, when it becomes able to accept a new entity, queries the upstream entity to pull the next entity if one is available. This push-pull mechanism requires links to be stored in both directions, and may also be generalized as the mode of connections between all components.

(Click on the “Step” button to advance through the model, refresh the page to run it again.)

Here’s the code for the Process component.

Here’s the code that initializes all the components.

The processing time was set to nine seconds so we can watch a nice collection of entities build up in the queue but which allows the system to completely empty out by the end of the simulation. Once the queue is continually not empty the process is engaged continuously.

Stepping through the simulation in this mode takes some patience, so once I get the Exit component incorporated I’m going to change things up a bit.

Posted in Simulation | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 28

Posted on October 19, 2016 by R.P. Churchill

Today I added a queue component, so the entities are generated by the Arrivals component, inserted at the Entry component, and forwarded to the Queue component. At this point the processes are all instantaneous, but they will get more interesting when the Process component is added tomorrow. It is assumed that the process represented by the Process component will not be instantaneous.

(Click on the “Step” button to advance through the model, refresh the page to run it again.)

Here’s the code for the Queue component, which contains the methods needed to receive and forward entities. The forwarding mechanisms have been added to the Entry component as well. The Queue component has code for forwarding items but I haven’t activated it yet. It does the following important things:

  • It maintains and displays a count of the number of items in the queue.
  • It stores the actual entities received in a local queue structure, which adds received entities to one end of the queue and takes forwarded entities off the other end of the queue.
  • It updates the entity elements with time stamps for when they enter and exit the queue. (Again, the exit mechanism is not yet used so all arriving entities just pile up in the queue.)

The Queue component clears its entry and exit information independently after two seconds, unless its data has been overwritten by the processing of a newer entity. This is the same thing I did for the Entry component but this has not been done for the Arrivals component. In truth I’m thinking none of the clearing operations are necessary, I just had a feeling they would make it easier to trace things visually as I was building the mechanism. I will probably switch off this behavior once I’m sure everything is working the way I’d like it to.

The messages have been updated and reordered a bit so everything is more consistent and easier to follow.

The Arrivals component actually destroys itself at the end of the simulation, and I should probably do that for the other components as well.

Posted in Simulation | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 27

Posted on October 18, 2016 by R.P. Churchill

Today I made a few tweaks, but the main thing was adding an Entry component and a means of moving entities through the model. Remembering that the entities are entirely passive, the components must be able to hand entities off to the next component, know what the next component is, and receive entities from the previous component.

First, here’s the model itself, which takes 80 or so clicks to run to the end.

Here’s the code for the entry component, which contains the methods needed to receive and forward entities. The forwarding mechanisms have clearly been added to the Arrivals component as well.

The only interesting thing the entry component does is clear its data display after two seconds, unless its data has been overwritten by the arrival of a newer entity.

The lines that initialize the components are here.

I also had to modify the function that displays formatted data, to make sure the desired formats are appropriate for the type of data expected. This came up when functions like toFixed and toPrecision choked when I assigned empty strings to generate a blank display. The fact that JavaScript is weakly typed makes it possible to do and one gets tempted to take advantage of such features.

Posted in Simulation | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 26

Posted on October 17, 2016 by R.P. Churchill

Having sorted out the internal reference issues in JavaScript I could go ahead and post the next update to the model framework. In this iteration the entities are completely passive, which means that the newly created entities are generated using a secondary puck within the ArrivalsComponent element. Repeatedly clicking on the “Step” button advances through the events one by one, up to 360 minutes. (40-ish clicks, refresh the browser to reset.)

I’ve included the code for the ArrivalsComponent element to show how the two pucks cooperate. Pucks become inactive when they aren’t reinserted into the future events queue (or the current events queue, but we’ll get back to that later). The main puck, the one associated with the blockIncrement method, is recycled every 30 minutes through the entire duration of the simulation. The secondary puck, associated with the makeEntity method, is reactivated as needed during every 30-minute cycle, and is recycled until all of the arrivals for that interval are created.

The newly created entities should be forwarded to some other location (i.e., actually injected into the model), and I’ve left a comment and blank line as a placeholder. This will get filled in as I create the other component types.

Right now I’m redrawing the display every time the activate method is called (at the end, after the work has been done) but later this operation will have to be called externally, so the displays for every element in the model can be redrawn during every update.

Finally, I cleaned up a few things to better follow JavaScript’s preferred naming conventions, use of ending semi-colons, and a few other things as suggested by WebStorm. (I maintain a full personal license for all of JetBrains‘ products.)

Here’s the code for the ArrivalsComponent itself.

Here are a couple of supporting items that need to be declared first.

Posted in Simulation | Tagged , | Leave a comment

A Simple Discrete-Event Simulation: Part 25

Posted on October 13, 2016 by R.P. Churchill

The solution is that there is no solution. The simplest thing to do is to ensure that the values are updated by hand whenever they need to be drawn. I’ve included a method called assignDisplayValues to the arrivals component. It should be called just before the drawBasicFunction. This feels wasteful and kludgy, but it seems like the most straightforward thing to do. Other solutions (like burying values in arrays) impose overheads of their own, so I figure it would be best to just be honest about what’s happening. In the long run this will be the most clear solution for the programmer.

I’m surprised that I hadn’t really appreciated this aspect of JavaScript until now, but perhaps I shouldn’t be. Every tool comes with a large number of features you simply won’t see until you do that first thing that forces you to. In the meantime I understand why this limitation is part of the language, but I also understand why people probably find it to be annoying (a word I seem to be using a lot recently…).

Posted in Simulation | Tagged , | Leave a comment