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]
