What is the meaning of the constraint formula for LossySync context-dependent
11 views
Skip to first unread message
Alireza Farhadi
Sep 15, 2012, 11:18:01 AM9/15/12
to reo...@googlegroups.com, Behnaz Changizi
Dear Members,
Recently I read great work of Behnaz Changizi about expressing Constraint Automata with Memory State for Reo connectors that supports integrating some different behaviors in one encoding : http://nkokash.com/documents/icsea2012.pdf
She has used Jos e Proen ca idea for primitive end status for modeling context-dependent behavior, but it's hard for me to detect operators priority. it was 2 scenario for me to read the constraint formula for LossySync context-dependent (the image of formula has been attached):
the first: (if there is a data on node "b" then (there is a data on node "a" and (the data on node "a" is equal to the data o node "b")) and (if (reason for lack of dataflow on source end of node "a" originates from context and also there is not data on "a") then reason for lack of dataflow on sink end of node b originates from itself)
the second: (if there is a data on node "b" then (there is a data on node "a" and (the data on node "a" is equal to the data o node "b")) and (reason for lack of dataflow on source end of node "a" originates from context and (if there is not data on "a" then reason for lack of dataflow on sink end of node b originates from itself))
or none of them, and my interpretation about primitive end status is totally is incorrect?
Regards,
Alireza Farhadi
Recently I read great work of Behnaz Changizi about expressing Constraint Automata with Memory State for Reo connectors that supports integrating some different behaviors in one encoding : http://nkokash.com/documents/icsea2012.pdf
She has used Jos e Proen ca idea for primitive end status for modeling context-dependent behavior, but it's hard for me to detect operators priority. it was 2 scenario for me to read the constraint formula for LossySync context-dependent (the image of formula has been attached):
the first: (if there is a data on node "b" then (there is a data on node "a" and (the data on node "a" is equal to the data o node "b")) and (if (reason for lack of dataflow on source end of node "a" originates from context and also there is not data on "a") then reason for lack of dataflow on sink end of node b originates from itself)
the second: (if there is a data on node "b" then (there is a data on node "a" and (the data on node "a" is equal to the data o node "b")) and (reason for lack of dataflow on source end of node "a" originates from context and (if there is not data on "a" then reason for lack of dataflow on sink end of node b originates from itself))
or none of them, and my interpretation about primitive end status is totally is incorrect?
Regards,
Alireza Farhadi
Pankaj Kasar
Sep 17, 2012, 5:04:16 AM9/17/12
to reo...@googlegroups.com, alireza...@gmail.com
All respected members
Can one of you help me in my project on TIME CONSTRAINT AUTOMATA from very basic things. I am currently working on modelling of business processes in my project. So if you help me by giving me web resources ,videos,or PDFs of basic concepts of Constraint automata. Hopping for your valueable guidance.
Thank you..!!!
Regards
PANKAJ KASAR
Can one of you help me in my project on TIME CONSTRAINT AUTOMATA from very basic things. I am currently working on modelling of business processes in my project. So if you help me by giving me web resources ,videos,or PDFs of basic concepts of Constraint automata. Hopping for your valueable guidance.
Thank you..!!!
Regards
PANKAJ KASAR
--
You received this message because you are subscribed to the Google Groups "reo-dev" group.
To post to this group, send email to reo...@googlegroups.com.
To unsubscribe from this group, send email to reo-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reo-dev?hl=en.
Jose Proenca
Sep 18, 2012, 4:16:56 AM9/18/12
to reo...@googlegroups.com, Behnaz Changizi, alireza...@gmail.com
Dear Alireza,
The intuition behind the variables that model context is the following:
- "a_c" is *T*rue means that the source end "a" sends a reason for
no-flow *T*o the connector.
- "a_k" is *F*alse means that the sink end "a" gets a reason for
no-flow *F*rom the connector.
Your expression is a conjunction of 3 elements. The first captures
synchronous and data constraints, as you pointed out. The second
$\lnot a_c$ imposes that "a_c" must be False, that is, the LossySync
must always get a reason From the connector for no-flow. Finally, the
last $\lnot a -> b_k$ says that, whenever there is no-flow on "a" (and
consequently also on "b" because of the first part of the
constraints), then "b_k" must be True, i.e., send a reason To the
connector.
Note that these constraints are slightly different from the context
constraints that me and Dave initially proposed. For example, in the
formula from Behnaz's paper the variable "a_c" is always requiring a
reason, independently of data flowing on "a". This kind of
optimisation only works by assuming that all source ports with flow do
not impose any restriction on the context-variables. In my
perspective, a safer approach would be write $\lnot a \to \lnot a_c$.
I hope this helps.
Best,
José
--
Jose Proenca
http://people.cs.kuleuven.be/~jose.proenca
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
The intuition behind the variables that model context is the following:
- "a_c" is *T*rue means that the source end "a" sends a reason for
no-flow *T*o the connector.
- "a_k" is *F*alse means that the sink end "a" gets a reason for
no-flow *F*rom the connector.
Your expression is a conjunction of 3 elements. The first captures
synchronous and data constraints, as you pointed out. The second
$\lnot a_c$ imposes that "a_c" must be False, that is, the LossySync
must always get a reason From the connector for no-flow. Finally, the
last $\lnot a -> b_k$ says that, whenever there is no-flow on "a" (and
consequently also on "b" because of the first part of the
constraints), then "b_k" must be True, i.e., send a reason To the
connector.
Note that these constraints are slightly different from the context
constraints that me and Dave initially proposed. For example, in the
formula from Behnaz's paper the variable "a_c" is always requiring a
reason, independently of data flowing on "a". This kind of
optimisation only works by assuming that all source ports with flow do
not impose any restriction on the context-variables. In my
perspective, a safer approach would be write $\lnot a \to \lnot a_c$.
I hope this helps.
Best,
José
--
Jose Proenca
http://people.cs.kuleuven.be/~jose.proenca
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Behnaz Changizi
Sep 18, 2012, 4:59:01 AM9/18/12
to reo...@googlegroups.com, Behnaz Changizi
Thank you Alireza for your interest in my work and thanks Jose for his explanations.
The coloring part of the constraint encoding for LossySync means that the source end of the channel can not provide a reason for no flow to the context of the source, if there is no flow, the reason originates from the context, in this case sink end explains the no flow reason to its context by giving a reason. The intuition behind this is that lack of flow from the sink perspective is due the channel not proving a data item to the context on its sink.
You also mention the operator priority, what do you mean by detecting the operator priority?
Best,
Behnaz
On Sat, Sep 15, 2012 at 5:18 PM, Alireza Farhadi <alireza...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages