Hi JS, Interesting idea. I'm not sure about the answer. This sounds a little bit like Boolean Dataflow (BDF) from Ptolemy Classic. The Ptolemy Classic docs say:
"Boolean dataflow was developed by Joe Buck as part of his Ph.D. thesis research [Buc93c]. Like DDF, it supports run-time flow of control. Unlike DDF, it attempts to construct a compile-time schedule. Thus it achieves the efficiency of SDF with the generality of DDF. It currently supports a somewhat more limited range of stars than DDF, and does not support recursion, but the model of computation is, in principle, equally general. Its applications are the same as those of DDF." "The basic mechanism used in BDF is to construct an annotated schedule, by which we mean a static schedule where each firing in the schedule is annotated with the Boolean conditions under which it occurs. Thus, any sequence of firings can depend on a sequence of Boolean values computed during the execution. Executing the annotated schedule involves much less overhead than executing a dynamic dataflow schedule." Ptolemy II does not have a BDF domain. Ptolemy II does have a DDF domain. I don't think DDF will conditionally execute blocks in the manner you describe. _Christopher -------- Hi all, I feel like this brings yet another problem. Suppose you have a dataflow graph that looks like: -------- ----------------- | A |--------->| | -------- | BooleanSelect |---> +---->| | -------- | ----------------- | B |----| -------- In the case where A sends a token at time t, it means that you actually wouldn't have to compute B at all since you know it will be flushed. The same problem arises with logical operators (e.g. AND, OR) and IFs. I'm worried about these issues since it has real consequences when dealing with real-time video for instance. Imagine A and B compute video and replace the BooleanSelect by a VideoSwitch actor that would allow you to choose wether you play A or B. In that case you need to know that you actually don't need to compute one of the two branches. Is there a solution for this in PtII? Is there a domain that can deal with these issues? Thanks, ++ js Richard van der Laan wrote: > Hello, > > I want to share a problem I ran into while executing a model containing a n instance of the BooleanSelect actor. > > In my scenario I embedded the Ptolemy kernel as a precalculation engine t o render motion setpoints > for servomotors. Here the setpoints are eventually buffered in actors whi ch abstract the servos. > The model execution thread is temporary paused when the buffers are full and is continued after hitting a certain > buffer threshold. Meanwhile in a different thread, batches of these buffe red setpoints are dispatched > to the servos. The execution of this process can last for hours. > > I discovered that only when my model contains a BooleanSelect actor the v m will eventually run out of memory. > After some profiling I traced the problem down to one of the receiver que ues of the BooleanSelect actor. > The PTII6 beta code shows that depending on the control state, either tok ens of trueInput or falseInput will be used: > > public void fire() throws IllegalActionException { > super.fire(); > if (_control) { > // Redo this check in case the control has changed since pref ire(). > if (trueInput.hasToken(0)) { > output.send(0, trueInput.get(0)); > } > } else { > if (falseInput.hasToken(0)) { > output.send(0, falseInput.get(0)); > } > } > } > > When the control state of the actor is true for all model iterations, onl y the tokens of trueInput are removed > from the underlying receiver queue. This means that all falseInput tokens remain in the other receiver queue, which > will eventually lead to an out of memory. I fixed this problem by removin g tokens from both the true and false inputs. > Depending on the control state, either the true or false tokens are send to the output: > > public void fire() throws IllegalActionException { > final boolean trueInputHasToken = trueInput.hasToken(0); > final boolean falseInputHasToken = falseInput.hasToken(0); > Token trueInputToken = null; > Token falseInputToken = null; > > if (trueInputHasToken) { > trueInputToken = trueInput.get(0); > } > > if (falseInputHasToken) { > falseInputToken = falseInput.get(0); > } > > if (_control) { > // Redo this check in case the control has changed since pref ire(). > if (trueInputHasToken) { > output.send(0, trueInputToken); > } > } else { > if (falseInputHasToken) { > output.send(0, falseInputToken); > } > } > } > > I'm not sure if I discovered a bug in the original implementation, but ne vertheless I like to share this with you all. > > Kind regards, > > Richard van der Laan, Luminis > Mobile: +31 (0)65 105 22 57 > Office: +31 (0)26 365 34 70 > Email : [EMAIL PROTECTED] > TheWeb: http://www.luminis.nl > LOSS : https://opensource.luminis.net > > > ------------------------------------------------------------------------- --- > Posted to the ptolemy-hackers mailing list. Please send administrative > mail for this list to: [EMAIL PROTECTED] > > > -- J. S. Senécal http://drone.ws --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED] -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]