FICO® Blaze Advisor® Discussion

[MikeD]

Hi,

I'm using Blaze Advisor 8.10 for Java.

this code:

-----------------

scarray is some array of SideCost initially an array of SideCost;

sc1 is some SideCost initially a SideCost;
sc1.name = "A";
sc1.amount = 100;
scarray.append(sc1);

sc2 is some SideCost initially a SideCost;
sc2.name = "A";
sc2.amount = 200;
scarray.append(sc2);

sc3 is some SideCost initially a SideCost;
sc3.name = "B";
sc3.amount = 400;
scarray.append(sc3);

if(every SideCost in scarray
such that it.name="C"
satisfies it.amount > 150) then
print("SATISFIES");

-----------------

produces this error:

com.blazesoft.engines.rules.NdEvaluationException: Evaluation error
Expression produces unexpected value: unknown.
unknown while evaluating every SideCost in scarray such that (it.name = "C") satisfies (it.amount > 150)

if I change |such that it.name="C"| to A or B everything works fine.

Seems, that "satisifies" clause fails if "such that" returns empty collection.

But the file "developingRuleProjects.pdf", page 389, section "limiting the set of objects to match" states, that the test expression is evaulated only on the objects, that satisfy constraint expression. Since with my example this is 0 objects, the "satisfy" clause should never be evaulated. Am I right?

How can I rewrite my code to work properly?

[TasMot]

I believe the following will solve the problem but not explain why you are getting it (please note extra set of parenthesis).

if(every SideCost in scarray
such that it.name="C"
satisfies (it.amount is known and it.amount > 150)) then
print("SATISFIES");

Tom

[MikeD]

Hi Tom,

your solution does not solve my problem. Have you tried my code on your Blaze Advisor?

I know I can rewrite the code like this:

if (at least one SideCost in scarray satisfies it.name="C") then {
satis is a boolean initially true;

for each SideCost in scarray such that it.name="C" do {
if (it.amount <= 150) then {
satis = false;
}
}

if(satis) then {
print("SATISFIES");
}
}

but this is an ugly workaround.

[Tas]

Hi,

     As it turns out, you were mixing "such that" which is used for loop control and patterns with the "satisfies" for the "every" version of the quantified expression (and I didn't notice).  I created a SideCost object with just name and amount properties, and the following worked (it printed not very satisfying):

scarray is some array of SideCost initially an array of SideCost;

sc1 is some SideCost initially a SideCost;
sc1.name = "A";
sc1.amount = 100;

scarray.append(sc1);

sc2 is some SideCost initially a SideCost;
sc2.name = "A";
sc2.amount = 200;
scarray.append(sc2);

sc3 is some SideCost initially a SideCost;
sc3.name = "B";
sc3.amount = 400;
scarray.append(sc3);

if(every SideCost in scarray
satisfies (it.name="C" and  it.amount > 150)
) then
{
 print("SATISFIES");
}
else
{
 print("Not Very Satisfying");
}
return;

     Tom Sheckells

     Business Rules Consulting, Inc.

[MikeD]

Hi,

yeah, I'm sure that this works, but it means something different.

My code first selects a subgroup (with "such that" name = A, B or C) and then checks if the condition is true ( it.amount > 150) only within this subgroup.

Try changing name = 'C'  to A or B. It should say SATISFIES for B and not for A. It also should not print anything for C. My original code works well for A and B, but according to documentation it should not evaluate 'satisfies' for C, but for some reason Blaze tries to do that. 

By the way, this is not my code, I'm just trying to fix a bug in a code written by a FICO consultant some time ago, so I assume this is a valid way to code. If it is not, can you point me to the section of documentation that says so?

[Tas]

Hi,

     I do believe that you are confusing process with results.  In a standard precedural processing language like Java, the first step would be to collect the subset of items where the name is "C"  and then to process the subset and find the items that match that amount > 150.  However; that is a process oriented task.  The result set is all items that have a name of "C" and an amount > 150.  My solution produces that result set in a single pass of the input set.  The process for arriving at that result set seems to be what you are arguing with.  In Blaze, there is more of a "set" processing methodology which doesn't require writing procedural code like you would in Java.

     My code sample is a slight modification from yours in that the final if statement prints something for every pass through the code so that I know which result was achieved.  This give me a positive confirmation of the result.  This means it always gives me a message to say the result of the test.  If in your final result you don't want a message printed for the else condition, that's fine, but for testing it will always explain what the result was.

     Tom Sheckells

     Business Rules Consulting, Inc.

[MikeD · Accepted solution]

Hi,

thank you for your input, but I think I'm doing exaclty what is described in the documentation. As I mentioned before, have a look at the file "developingRuleProjects.pdf", page 389, section "limiting the set of objects to match".

My rewritten code procedurally does what I want. My original code should (in my opinion according to the documentation) do exactly the same in a declarative (results oriented) manner.

This section of documentation mentions that "such that" can be used in if-then statements, and it works as described for A and B (I haven't run your code, but I'm pretty sure it will deliver different results, since it does not check the "satisifies" withinin the subset defined by "such that").

I already filed a support request, but if there is something I'm missing here, please explain it in more detail.