Modeling computed boolean based on integer value

Hello.

I fear this is similar to this question: How to calculate boolean fields - Kernel - mgm A12 Discourse

I have a Number-field and out of it’s value, I want to calculate another boolean field.

What is the issue here?

Kind Regards,
Stefan

Hey @stefan-cached-grove,

You try to use the implicit result of the comparison “([NumberImport] == 10)” as an output.
This is currently not supported by the Kernel Language.
Please make the result explicit by adding "And [NumberImport] == 10 " to the Precondition and using " True " as the Calculation (enter without the quotes).

If your approach would work, you would have three states for BooleanComputer :
BooleanComputer = Null if NumberImport is empty
BooleanComputer = True if NumberImport is 10
BooleanComputer = False if NumberImport in all other cases

Is this your expected outcome or would you rather want to have BooleanComputer to have only two states? If so, consider using a Field Type Confirm.

Hey, thanks for explanation.

To put everything else to ‘False’ I come to the following solution: Add a second Computation-Rule with no precondition, calculation would resolve to “False”. Because kernel computes from top to down, it would try to execute the first computation (precondition not matched) and then executes the second computation-rule (=everything else) and set it to ‘False’.

Hi @stefan-cached-grove
unfortunately, the following is incorrect

Attached is a 2024.06 model which is correctly modeled using your original computation, the suggestion from @felix-blazing-river and your follow-up requirement.
BooleanComputer_DM.json (9.9 KB)

Different options have been modeled using booleans or confirm fields. Please check the model and use ad-hoc test for more information.


Explaination
Whilst the Kernel computes from “the top down”, having multiple preconditions that are true creates an invalid document as more than one value is correct. You see the error

“error text for computation of <MyComputationRuleName>”

Your suggestion is also not achievable in the SME as a precondition must be added when more than one item is present in the computation table.

This is documented in the Kernel Language Documentation.

Hello,

Thanks Malcolm for your reply.

I don’t understand, why a Computation for Boolean-Values requires a precondition. If I want to model a fallback or a “default Value”, in my case the “False” it would be necessary to negate a (potential very complex) business rule.

I tried some preconditions (for further reference)
Does not work:

  • True == True
  • True AND True

Does work:

  • 1+1 == 2 :slight_smile:

Any recommendations appreciated.

Hi @stefan-cached-grove,

Computations Rules do not always require a precondition.

However, Computation Rules with more than one Precondition Calculation pair in the Table need to have preconditions modeled for all rows of the table. This is enforced as the preconditions must exclude each other (see my previous link to the Kernel Language Documentation).

Modeling a precondition that is always true, such as:
1+1==2
means that your preconditions almost certainly overlap with each other. This will lead to the error I mentioned, “error text for computation of <MyComputationRuleName>”, when fully validating the document.

The only correct way to model this is to model (a potentially very complex) precondition that reflects when “False” should be returned.

Alternatively, you can start the process of filling a requirement to extend the A12 functionality to allow “else” conditions in the Kernel Language.

Hi @malcolm-silver-ice ,

Thanks for explanation.

Yes, I want to model an “everything else” case, which resolves to ‘False’.

Because the rules are executed in order (top to down), I do not agree on the “overlap with each other” argument. Businessly it is correct, but timely, not.

I will discuss an “else condition” requirement with my team, but for now I will go with my ‘always true’ precondition in the else-part.

To be clear, when you ask

The recommendation is to never model an “always true” precondition when you have more than one entry in the computation table.

My understanding is that your document will be invalid if the computation rule returns two or more values because two or more preconditions are true at the same time.

I would not recommend your workaround.

Granted.

My precondition is

(FieldFilled(afield) AND [afield] != "XXX") AND (FieldFilled(anotherfield) AND ([anotherfield] == X OR [anotherfield] == Y))

And it’s the only case for true. Everything else is false. And I look for a simple solution to model that.

Let’s break down your Precondition.

(FieldFilled(afield) AND [afield] != "XXX")

can be easily expressed with a language construct:

FieldValueNotIncludedInValueList(afield, "XXX")

The same is true for your other condition assuming X and Y are strings, numbers or enumeration values.

(FieldFilled(anotherfield) AND ([anotherfield] == X OR [anotherfield] == Y))

equates to:

FieldValueIncludedInValueList(anotherfield, X, Y)

This means that your precondition can be expressed as:

FieldValueNotIncludedInValueList(afield, "XXX")
And
FieldValueIncludedInValueList(anotherfield, X, Y)

Please note, both Language Constructs require the referenced field to be filled. If the referenced Field is not filled, then the condition is not satisfied. You could add AllFieldFilled(afield,anotherfield) to make this explicit.

The opposite condition is simply modeled by reversing those Language Constructs:

NotAllFieldsFilled(afield, anotherfield) 
Or FieldValueIncludedInValueList(afield, "XXX")
Or FieldValueNotIncludedInValueList(anotherfield, X, Y)

See attached 2024.06 model
BooleanComputer2_DM.json (3.9 KB)

@stefan-cached-grove: I would like to add some details in order to support @malcolm-silver-ice’s advices:

  1. Kernel evaluates the computation alternatives from top to down, as already stated in this thread.
  2. As soon as the precondition of an alternative is fulfilled, the value for the field is computed based on the defined operation in the corresponding alternative (I think that this is also clear).
  3. BUT, Kernel also creates internally a validation rules out of the computation-rule.

Let’s have a look at the following example to understand better the situation:
Computed field: aCompField
Precondition 1:

FieldFilled(aField) AND [aField] != "XXX"

Operation 1:

True

Precondition 2 (always true):

1+1=2

Operation 2:

False

The resulting validation rule would be (it is not complete, but I refer to the most important parts):

(FieldFilled(aField) AND [aField] != "XXX" AND [aCompField] != True)
OR
(1+1=2 AND [aCompField] != False)

Basically,

  • the precondition and the operation of a single alternative are connected to each other,
  • the operation of the alternative (computed value) is “assigned” to the computed field, and
  • both alternatives are connected via an OR operator.

Having a data set for which the computed value for aCompField is True, the first part of the validation-rule

FieldFilled(aField) AND [aField] != "XXX" AND [aCompField] != True

evaluates to ‘false’ (until now, the validation rule wouldn’t fire), whereas the second part

1+1=2 AND [aCompField] != False

evaluates to ‘true’ and since both parts are connected with an OR operator, the rule will definitely fire.
An else-statement would be, from Kernel point of view, a meaningful requirement.

Thanks @malcolm-silver-ice and @gildardo-cached-canyon for your analysis and hints.