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