hehe, so I walked into this one with my eyes wide shut :)<br><br>Given it is only possible to define implicit logical AND's between field constraints within a decision table and given it is not possible to introduce complexity with parenthesis, is the immediate problem domain smaller than the more generalised discussion surrounding "otherwise" or "else"?<br>
<br>The first limitation can be overcome by converting multiple single field constraints on the same field to a single compound field constraint on the same field; thus:-<br><br>r1: age > 14, age <= 28 (i.e. age > 14 && <= 28) becomes<br>
rx: age <= 14 || > 28<br><br>I wonder whether this problem cannot simply be resolved with application of DeMorgan's Theorems (something I know a little about from studying electronics as a student years ago).<br>
<br>Unlike some commentators I am not an expert in first order logic, and
therefore would appreciate guidance if people are willing to help.<br>
<br>Thanks,<br><br>Mike<br><br><div class="gmail_quote">On 1 April 2011 07:02, Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Michael,<br>
<br>
My position is that an otherwise for a single column is likely to<br>
cause trouble by misunderstandings. Especially the operators >, >=, <,<br>
<= are likely to be used to separate intervals, as in<br>
r1: age > 14, age <= 28<br>
r2: age > 28, age <= 42<br>
<br>
If you apply the proposed definition, the otherwise results in<br>
rx: age <= 14, age > 42<br>
which is obviously never true.<br>
<br>
You can construct similar blackouts with two different fields, e.g.<br>
r1: age > 60, income > 100000<br>
r2: age > 40, income > 80000<br>
<br>
You will have to do an in-depth analysis of the AST resulting from the<br>
condition definition resulting from rule table lines $n+2 and $n+3 in<br>
order to get it right.<br>
<br>
My opinion is: Don't do it unless you can do it right.<br>
<br>
Cheers<br>
<font color="#888888">Wolfgang<br>
</font><br>
PS: I could provide a definition for otherwise with matches and<br>
soundslike, but I'd rather not.<br>
<div><div></div><div class="h5"><br>
<br>
On 31 March 2011 21:25, Michael Anstis <<a href="mailto:michael.anstis@gmail.com">michael.anstis@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I'm adding support for "otherwise" to (for the time being) the guided<br>
> decision table in Guvnor.<br>
><br>
> The idea being if you set a cell to represent "otherwise" the generated rule<br>
> is the opposite of the accumulation of the other cells; perhaps best<br>
> explained with an example:-<br>
><br>
> Person( name == )<br>
> Mark<br>
> Kris<br>
> Geoffrey<br>
> <otherwise><br>
><br>
> This would generate:-<br>
><br>
> Person(name not in ("Mark", "Kris", "Geoffrey")<br>
><br>
> Equals is the simple example, this is my thoughts for the other operators we<br>
> might like to support:-<br>
><br>
> != becomes "in (<list of the other cells' values)"<br>
> < becomes ">= the maximum value of the other cells' values<br>
><br>
> For example:-<br>
><br>
> Person ( age < )<br>
> 10<br>
> 20<br>
> 30<br>
> <otherwise><br>
><br>
> Person ( age >= 30 )<br>
><br>
> <= becomes "> the maximum value of the other cells' values<br>
>> becomes "<= the minimum value of the other cells' values<br>
>>= becomes "< the minimum value of the other cells' values<br>
> "in" becomes "not in (<a list of all values contained in all the other<br>
> cells' lists of values>)"<br>
><br>
> For example:-<br>
><br>
> Person ( name in )<br>
> Jim, Jack<br>
> Lisa, Jane, Paul<br>
> <otherwise><br>
><br>
> Person ( name not in ("Jim", "Jack", "Lisa", "Jane", "Paul" ) )<br>
><br>
> I'm not sure there is a simple solution for "matches" and "soundslike" but<br>
> welcome advice, although a possibility might be to create a compound field<br>
> constraint:-<br>
><br>
> Person ( name soundslike )<br>
> Fred<br>
> Phil<br>
><br>
> not Person ( name soundslike "Fred" || soundslike "Phil" )<br>
><br>
><br>
> Would this be considered the most suitable approach?<br>
><br>
> Inputs and thoughts welcome.<br>
><br>
> Thanks,<br>
><br>
> Mike<br>
><br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> rules-dev mailing list<br>
> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
><br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</div></div></blockquote></div><br>