RE: binds

Hi all,

<martin>
3) Why predicates are restricted in 6.4.2? How would you do e.g. something
like "Copy the value from "a/b" if "a/c" is 1":

	calculate="a/b[../c=1]"

when dynamic predicates are not allowed?
</martin>

<micah>
> 3) Dynamic predicates introduce the possibility
> of various kinds of loops in
> the dependency tree. We don't want recalculations
> to take very long (including infinite!) amounts
> of time. Thus, dynamic predicates are never
> allowed.
</micah>

<martin>
So, instead of writing 
	calculate="a/b[../c=1]"
you would allow only
	calculate="if(a/c=1, a/b, '')"
correct? What's the difference?
And if you allow neither the second version, what code would you use to
provide the same functionality?
</martin>

<micah>
I'm referring your dynamic bind question over to John Boyer, our calculation expert.
</micah>

<john>
To assuage your concerns right away, I'll begin by saying that the second calculate which uses the 'if' function is permissible and operates in the manner you require.

Regarding the question of what is the difference:

The first calculate sets up a 'dynamic' computational dependency.  The node(s) to which it is bound is(are) dependent on a/b only if a/c is equal to 1.  The second calculate sets up static computational dependencies.  The node(s) to which it is(are) bound are always dependent on a/b and a/c.  If either a/b or a/c are changed, we know we need to rerun the 'if' function to find out what the result will be.

The calculation engine builds a 'computational dependency digraph' that represents how to change computationally related instance elements based on an initiating change (e.g. user input).  We do not want this graph to change, esp. not during a recalculation.  Suppose for example that you have an an instance in which a/c starts out not being equal to 1.  Suppose that your example calculate="a/b[../c=1]" were bound to some node X.  Well, when we start, the result of the calculate is an empty nodeset, so X is dependent only on a/c.  Now suppose the user enters some input that causes a/c to become equal to 1.  The calculation engine would see that X needs to be recalculated, so everything behaves as you would like so far.  Now suppose the user enters some data that changes a/b.  You would expect X to be changed, but X is only dependent on a/c, so it does not get updated.

In this tiny example, one could easily see the system updating the dependencies for X when it is reevaluated, but in anything except trivial examples like this it quickly becomes very difficult to manage because changes of value during a recalculation would actually change the calculation order, so doing things like computing the pertinent dependency subgraph are non-starters because the pertinent subgraph is changing dynamically.  So instead of this big headache, we have the 'if' function that allows you to do what you want while simultaneously imposing a style of expression that creates static dependencies.

Best regards,
John Boyer, Ph.D.
Senior Product Architect
PureEdge Solutions Inc.
</john>

Received on Friday, 22 March 2002 17:56:29 UTC