adobe-source-devel

[Adobe-source-devel] Questions about conditional_indirect_contributing_m

[cee1 <fy...@gm...>]

Hi all,
I'm reading the code of asl 1.0.42.
Some questions about *conditional_indirect_contributing_m*:
I found "*conditional_indirect_contributing_m*" (data member of
sheet_t::implementation_t) is *only set* in function
sheet_t::implementation_t::update:
(adam.cpp, 1119) accumulate_contributing_m.reset ();
...
(adam.cpp, 1143) conditional_indirect_contributing_m
= accumulate_contributing_m;

It seems conditional_indirect_contributing_m will always be zero, and is
referenced as "a_variable |= conditional_indirect_contributing_m", should it
be useless? What is conditional_indirect_contributing_m doing?

BTW, I've read the introduction at http://stlab.adobe.com and the paper
"Property Models -- From Incidental Algorithms to Reusable Components", I'm
still confused about:

   - What is the difference between output and interface cells?
   - Data flow of various cells? (e.g. data from input cell only flow to
   output|interface cell? output|interface cell only accept data from input
   cell?)
   - What is the difference between input and interface cells(e.g. why input
   cell setting init_contributing_m while interface cell(input) setting
   contributing_m)?
   - Are relation cells only involved in "getting" value of interface cells
   (output)?
   - What is invariant cell doing? If an invariant cell evaluated "false",
   all cells contributing to it will be marked poison?


Regards
-- cee1

Re: [Adobe-source-devel] Questions about conditional_indirect_contributing_m

[Sean P. <sea...@ma...>]

Hi cee1,

Release 42 was a bit rushed and there are a couple of bugs in the adam  
code - the current mainline should be in could shape. I'm going to use  
that code for this discussion - you can see it here:

http://stlab.adobe.com:8080/@lno=y@//adobe_source_libraries/source/adam.cpp?ac=64&rev1=23

On Feb 13, 2010, at 3:21 AM, cee1 wrote:

> Hi all,
> I'm reading the code of asl 1.0.42.
> Some questions about conditional_indirect_contributing_m:
> I found "conditional_indirect_contributing_m" (data member of  
> sheet_t::implementation_t) is only set in function  
> sheet_t::implementation_t::update:
> (adam.cpp, 1119) accumulate_contributing_m.reset ();

Adjusting line numbers:

  1162.	    accumulate_contributing_m.reset();
> ...
> (adam.cpp, 1143) conditional_indirect_contributing_m =  
> accumulate_contributing_m;

And:

  1186.	    conditional_indirect_contributing_m =  
accumulate_contributing_m;

>
> It seems conditional_indirect_contributing_m will always be zero,  
> and is referenced as "a_variable |=  
> conditional_indirect_contributing_m", should it be useless? What is  
> conditional_indirect_contributing_m doing?


No - accumulate_contributing_m is a member variable and will  
accumulate bits (denoting cells) as variables are looked up when a  
cell expression is evaluated (variable lookup is bound to  
sheet_t::get()). Same discussion as on this prior thread <http://sourceforge.net/mailarchive/forum.php?thread_name=999EDB9A-2AFD-4E03-B3BA-97C1193FB8F1%40mac.com&forum_name=adobe-source-devel 
 >.

> What is conditional_indirect_contributing_m doing?


A relation can be conditional using a when() clause:

when (p) relate {
	x <== y;
	y <== x;
}

The conditional predicates are evaluated prior to flowing the  
relationships. conditional_indirect_contributing_m is an accumulation  
of all cells contributing to the conditional predicates. These  
indirectly contribute to any cell which is in calculated after.

>
> BTW, I've read the introduction at http://stlab.adobe.com and the  
> paper "Property Models -- From Incidental Algorithms to Reusable  
> Components", I'm still confused about:
> What is the difference between output and interface cells?
The implementation of interface cells is a pair of cells,  
interface_input and interface_output. An interface cell (and only an  
interface cell) can be involved in a relate clause and  for any state  
in the system either the input half is contributing or the output half  
is derived (or both if there is a self-reference loop).

> Data flow of various cells? (e.g. data from input cell only flow to  
> output|interface cell? output|interface cell only accept data from  
> input cell?)

See slide 66 here <http://stlab.adobe.com/wiki/images/0/00/2008_04_03_accu.pdf 
 >

> What is the difference between input and interface cells(e.g. why  
> input cell setting init_contributing_m while interface cell(input)  
> setting contributing_m)?

Interface cells are used to seed the sheet during initialization. We  
track the contributing values during initialization because a sheet  
can be "re-initialized" (this would happen if the state of something  
the sheet relies on was updated outside of the sheet). An input cell's  
value can only be set from code external to the sheet, where as the  
value in an interface cell (input side) can be applied from the output  
side fo the same cell. You can only bind an interface cell to  
something like an edit text widget because the input side can be set  
(controller side of widget) and the output side is displayed (view  
side of widget).

> Are relation cells only involved in "getting" value of interface  
> cells (output)?
A relation cell holds the bundle of expressions that binds the input  
side of the interface cell to the output side of the interface cell,  
along with any conditional predicates.

> What is invariant cell doing? If an invariant cell evaluated  
> "false", all cells contributing to it will be marked poison?
Correct, and then any cell derived from poison is marked as invalid.  
Consider a simple form where you must specify an age and the age must  
not be less than 21.

sheet drinking_test {
   interface:
     age : 0;
   invariant:
    age_test <==  !(age < 21);
   output:
    result <== age;
}

A layout to bind to this might look like:

layout drinking_test {
	view dialog() {
		edit_number(name: "Age", bind: @age);
		button(name: "Drink!", bind: @result);
	}
}

Here if age < 21 then age_test is false so age is marked as poison,  
result is derived from age so it is marked as invalid. The Drink!  
button, which is bound to result, will use the invalid flag to control  
enablement and will be disabled (a button invokes some function, and  
the value it is bound to is the arguments to that function, so if the  
arguments are invalid, then the pre-conditions of the function are not  
satisfied, and the button is disabled).

Hope that help,
Sean


>
> Regards
> -- cee1
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as  
> DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] Questions about conditional_indirect_contributing_m

[cee1 <fy...@gm...>]

Hi Sean,
Thanks for your reply, that's really helpful.

Release 42 was a bit rushed and there are a couple of bugs in the adam code
> - the current mainline should be in could shape. I'm going to use that code
> for this discussion - you can see it here:
>
>
> http://stlab.adobe.com:8080/@lno=y@//adobe_source_libraries/source/adam.cpp?ac=64&rev1=23
>
> I'll checkout the latest code by perforce.

The conditional predicates are evaluated prior to flowing the relationships.
> conditional_indirect_contributing_m is an accumulation of all cells
> contributing to the conditional predicates. These indirectly contribute to
> any cell which is in calculated after.
>
My original thought is, some cells may not be involved in conditional relate
clause, so their contributing_m should not
"|= conditional_indirect_contributing_m"?


>    - What is the difference between output and interface cells?
>
> The implementation of interface cells is a pair of cells, interface_input
> and interface_output. An interface cell (and only an interface cell) can be
> involved in a relate clause and  for any state in the system either the
> input half is contributing or the output half is derived (or both if there
> is a self-reference loop).
>
Can I say "interface cell is invented for the case of (direct or indirect)
self-reference"? (In this case, the value of interface cell will either be
"state_m of interface cell (input side)" or "term_m() of interface
cell(output side)"?)


>
>    - Data flow of various cells? (e.g. data from input cell only flow to
>    output|interface cell? output|interface cell only accept data from input
>    cell?)
>
>
> See slide 66 here <
> http://stlab.adobe.com/wiki/images/0/00/2008_04_03_accu.pdf>
>
I don't learn the detailed scenario of adam very well. The slide shows me
some, very helpful.


>    - What is invariant cell doing? If an invariant cell evaluated "false",
>    all cells contributing to it will be marked poison?
>
> Correct, and then any cell derived from poison is marked as invalid.
> Consider a simple form where you must specify an age and the age must not be
> less than 21.
>
What if an invariant cell evaluated "false" because the value of
one contributing cell is invalid (say other contributing cells have valid
values), then any cell derived from those "other" valid contributing cells
is marked as invalid?
Should I write "proper granularity" of invariant cell to avoid this problem?


Thanks
-- cee1

Re: [Adobe-source-devel] Questions about conditional_indirect_contributing_m

[Sean P. <sea...@ma...>]

On Feb 14, 2010, at 2:31 AM, cee1 wrote:

> Hi Sean,
> Thanks for your reply, that's really helpful.
>
> Release 42 was a bit rushed and there are a couple of bugs in the  
> adam code - the current mainline should be in could shape. I'm going  
> to use that code for this discussion - you can see it here:
>
> http://stlab.adobe.com:8080/@lno=y@//adobe_source_libraries/source/adam.cpp?ac=64&rev1=23
>
> I'll checkout the latest code by perforce.
>
> The conditional predicates are evaluated prior to flowing the  
> relationships. conditional_indirect_contributing_m is an  
> accumulation of all cells contributing to the conditional  
> predicates. These indirectly contribute to any cell which is in  
> calculated after.
> My original thought is, some cells may not be involved in  
> conditional relate clause, so their contributing_m should not "|=  
> conditional_indirect_contributing_m"?

It may be overly conservative - I'd have to spend some time looking  
again. The problem is that it is difficult to know how a relate clause  
being active or inactive will effect the system, so the stance is that  
it effects everything.

>
>> What is the difference between output and interface cells?
>
> The implementation of interface cells is a pair of cells,  
> interface_input and interface_output. An interface cell (and only an  
> interface cell) can be involved in a relate clause and  for any  
> state in the system either the input half is contributing or the  
> output half is derived (or both if there is a self-reference loop).
> Can I say "interface cell is invented for the case of (direct or  
> indirect) self-reference"? (In this case, the value of interface  
> cell will either be "state_m of interface cell (input side)" or  
> "term_m() of interface cell(output side)"?)

The name "interface" comes from their duel role of input/output. If  
you get the value of the cell, you always get the value of the term  
unless it is a self-reference (that is, you are getting the value of  
the cell as part of evaluating the term on the cell:

A term is always present - The following two statements are equivalent:

interface:
	a;

interface:
	a <== a;

Because of the duel role that interface cells have, they are the only  
cells that can appear in a relate clause.

>
>
>> Data flow of various cells? (e.g. data from input cell only flow to  
>> output|interface cell? output|interface cell only accept data from  
>> input cell?)
>
> See slide 66 here <http://stlab.adobe.com/wiki/images/0/00/2008_04_03_accu.pdf 
> >
> I don't learn the detailed scenario of adam very well. The slide  
> shows me some, very helpful.
>
>> What is invariant cell doing? If an invariant cell evaluated  
>> "false", all cells contributing to it will be marked poison?
>
> Correct, and then any cell derived from poison is marked as invalid.  
> Consider a simple form where you must specify an age and the age  
> must not be less than 21.
> What if an invariant cell evaluated "false" because the value of one  
> contributing cell is invalid (say other contributing cells have  
> valid values),

The definition of if a cell is poison is if it contributes to an  
invariant - so you can't really say a single invariant was violated  
because of any particular cell contributing to it - all cells  
contributing to it cause the problem.

> then any cell derived from those "other" valid contributing cells is  
> marked as invalid?
> Should I write "proper granularity" of invariant cell to avoid this  
> problem?

Yes - each invariant should test a unique issue.

There is an issue I'd like to get around to fixing with invariants -  
they currently aren't associated with any particular output cell  
(except through the dependencies) - so lets say you wanted a sheet  
with two main results - one is going to be used for shipping USPS, the  
other by Fed-Ex you might want something like:

invariant:
	can_fedex <== is_not_po_box(address);
output:
	fedex <== [address, purchase];
         usps <== [address, purchase];

But you can't do this, because the can_fedex test will poison the  
address and make usps invalid as well. You can hack it with something  
like:

interface:
  //...
    poison : false;
invariant:
    invalid <== poison;
logic:
    can_fedex <== is_not_po_box(address);
output:
    fedex <== [can_fedex ? address : poison, purchase];
    usps <== [address, purchase];
}

The initial design was considering multiple actions being bound to the  
same sheet. Ideally, an invariant could be associated directly with an  
output cell.


>
>
> Thanks
> -- cee1