Logically Equivalent vs Structurally Different

Eric Moore discusses how Corticon decision services view documents as logical based objects. Learn more about how this results in better performance.

Eric A. Moore, Software Architect at Progress and a cofounder of Corticon, discusses how Corticon decision services view documents as logical based objects as opposed to structural based objects. The result is better performance (as rule complexity increases) with the loss of document structure ordering. This can be seen quite often in where rules there is logical equivalency in the entities of the input document, resulting in a possible different ordering of output values each execution.

Corticon decision services process data by keeping things logically equivalent. What this means to the user is that the input data is viewed as an un-ordered collection of entities (Bag). This can result in some different outputs if the data is viewed as an ordered collection (List).

Logically equivalent data may cause different results on each execution due to order of processing.

Take for example this rulesheet:

This rulesheet takes as input a set of entities that have a value attribute set. The output will be that each entity will be given a count attribute, starting with one and incrementing by one, set incrementally so that the smallest value is one and so on up to the greatest value. No two entities will have the same count on output.

The alias e1 and e2 are mapped to the same entity and are filtered to be not equal.

Rule A0 initializes the count attribute of all entities to one.

Rule one handles the case where e1.value is less than e2.value and will add one to e2.count (since the value is higher).

Rule two handles the case where e1.value equals e2.value and will add one to e2.count (note that if there are multiple entities with the same value the actual mappings of these entities to e1 and e2 are logically arbitrary, however different mappings could result in a different ordering of equivalent entities).

Rule three handles the case where e1.value is greater than e2.value and will add one to e1.count.

Consider this data:

The Input contains four entities, so the result we expect is the count value being set to 1,2,3,4 for each entity in ascending order of the value attribute.

Note that Entity_1[2] and Entity_1[4] have the value attribute set at two, so there is an ambiguity here on which one should have count = 2 and count = 3.

Actually there are only two possible outcomes for this input, one is shown in the Output column and the other is shown in the Expected column.

If the data is looked at as an Ordered List, the output and expected do not match, they are structurally different.

However, if the data is looked at as an Unordered List or Set (the entity Ids are not considered) there is a logical match between the output and expected.  They are logically equivalent.

Corticon processes data as an Unordered List or Set, thus results may differ from run to run when viewed as an Ordered List.