Interesting...
How about the following: Suppose that find the least fixed point,
which is deterministic, and then assign _all_ widths that resolve to
0 the value 1.
Will that work?
Edward
At 09:36 PM 1/3/2006 -0800, Haiyang Zheng wrote:
Setting the default width 0 for all connections might not work. Here is why.
In order to resolve the widths of connections with the default width 0,
one algorithm is to infer widths based on a flat CPO. The CPO contains
Natural numbers and 0 as its elements, where 0 is the bottom element, 0
is less than the other elements, and the Natural numbers are not comparable.
Each time we examine the constraints on both sides of a connection, we may
determine the width of the connection as a natural number. If we cannot do
that, the width will be left unchanged. When no width of connections can
be changed, and some of them are still 0, we may randomly pick up one
connection and assign its width to 1. Then we reexamine the rest of
connections to see if their widths can be resolved. We keep doing this
until all widths are resolved.
Note that the chains in flat CPO has a depth 2, which guarantees the
algorithm to terminate in a finite number of iterations (similar to the
fixed point theorem in the SR semantics). In other words, once the width
of a connection is inferred, it cannot be changed afterwards.
This algorithm is simple and easy to be implemented. However, there is a
subtlety which may cause some nondeterministic results. The cause is the
random pick up of a connection with width 0. Suppose there is an output
port at the boundary of a composite actor, it has one inside connection
and three outside connections. None of the connection can determine its
width. Depending on the choice of connection to assign width 1, we may end
up with different widths for the inside connection. (Assume we allow the
sum of the widths of incoming connections to be different from that of the
outgoing connections.) Things get more complicated if the port has more
than one inside connection.
I cannot find a better, or systematic, way to pick up a connection to
assigh width 1. I do not know whether that will be possible. There may be
other better algorithms that I have missed. Comments are greatly appreciated.
Haiyang
----- Original Message ----- From: "Edward A. Lee" <[EMAIL PROTECTED]>
To: "Andre" <[EMAIL PROTECTED]>
Cc: <ptolemy-hackers@bennett.EECS.Berkeley.EDU>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 03, 2006 5:46 PM
Subject: Re: CompositeActor
The problem is that the connection inside in the composite has width 1.
If you double click on the connection and set the width to 2, then the
behavior is the same for both models. If you set the width to 0, then
the width will automatically be inferred to be 2 (or to be equal to however
many connections you make on the outside), and again the behavior will be
the same for both models.
I agree that this behavior is rather subtle. I'm not sure what a better
solution would be...
Perhaps a reasonable alternative design would be to make the default width
0 for all connections, and when there is no other basis for determining the
width, infer it to be 1.
I've cc'd Haiyang Zheng, who most recently worked on this inference engine,
for comments on whether this makes sense.
Edward
At 12:43 AM 1/4/2006 +0100, Andre wrote:
If I have a CompositeActor containing just an input port and a display
sink and connect that to a DE domain model it gives other results than
connecting the display directly. See attached moml for an example.
Can someone tell me if this is intended and why. How can I avoid that?
Thanks
andre
------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal
------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
