Allowing delays on inputs

The cast to const FloatMatrix * above is not always safe. Even if the source primitive is known to provide matrices of the appropriate type, a delay on the arc connecting the two primitives can cause problems. In particular, delays in dataflow domains are implemented as initial particles on the arcs. These initial particles are given the value ”zero” as defined by the type of particle. For Message particles, ”zero” is an uninitialized Message particle containing a ”dummy” data value. This dummy Message will be returned by the myData method in the third line of the above code fragment. The dummy message is not a FloatMatrix , rendering the above cast invalid. A primitive that expects matrix inputs has to have code to handle empty particles. An example is:

Envelope tInPkt;
(Input%0).getMessage(tInPkt);
if(tInPkt.empty())
{
  FloatMatrix& tResult = *(new FloatMatrix(int(numRows),
                                           int(numCols)));
  tResult = 0.0;
  Output%0 << tResult;
}

There are many ways that an empty input can be interpreted by a primitive which operates on matrices. For example, a primitive multiplying two matrices can simply output a zero matrix if either input is empty. A primitive adding two matrices can output whichever input is not empty. In the example above, the output matrix has the dimensions as set by the state parameters of the primitive so that any primitive that uses this output will have valid data. A possible alternative to outputting a zero matrix is to simply pass that empty MessageParticle along. This approach, however, can lead to counterintuitive results. Suppose that the empty message reaches a display primitive like TkText, which will attempt to call the print() method of the object. An empty message has a print() method that results in a message like

This is most likely to prove extremely confusing to users, so it is strongly recommend that each matrix primitive handle the empty input in a reasonable way, and produce a non-empty output.