[fpc-pascal] best method: multiple three state options in a decision tree

[waldo kitty]

On 1/21/2014 10:21 AM, Mattias Gaertner wrote:
> On Tue, 21 Jan 2014 09:51:38 -0500
> waldo kitty <wkitty42 at windstream.net> wrote:
>
>> On 1/18/2014 7:40 PM, waldo kitty wrote:
>>>
>>> what is the best method of coding a decision tree with options that have three
>>> states and all options are additive?
>>>
>>> clarification: i have a situation with 5 (at this time) options and all 5 are
>>> three state... each option can be paired with all other options' states but may
>>> NOT be paired with its own other states...
>> [...]
>>
>> no one has any ideas or thoughts on this?
>
> Maybe I don't understand the question.

that's quite possible... it took me a while to write it the way i did after 
starting over numerous times... i may have also used the wrong terms for what i 
was trying to describe as well as not giving enough examples but the example 
list was getting too large at that point anyway ;)

> The 5 options with each 3 states sounds like an array[1..5] of TRedGreenBlue.

a lot of stuff i googled up related to 3states came up with similar... to me 
that reads as to be used for graphics and this is a console app with no graphics 
involved... i'm only using the bits to denote the combinations available... they 
select which IF statement is used in the actual filter code described below...

originally i had thought of using an array but i didn't know the size of it and 
each grouping varies with the number of options...

> What do you mean with "additive"

logical AND with some combinations being invalid...

eg:
optionA:min/max {solitary}
optionB:max only AND optionE:min only {two ANDed together}
optionA:min only AND optionB:min/max AND optionC:max only {three ANDed together}

optionA:min/max AND optionA:min only {invalid}
optionA:min/max AND optionA:max only {invalid}
optionA:min only AND optionA:max only {invalid}

> and why a decision tree?

because it is used as the (right now) output filter ("tree" of "decisions" to be 
made) determining what gets written to the resulting file from the (currently) 
30000+ entries loaded in a sorted, no-dupes collection... there are also plans 
to implement the exact same thing as an input filter to limit the data being 
loaded into the collection...

eg:
case foo of
   0 : writeoutput;
   1 : begin
         if (rec^.optionA >= optionA_min) and (rec^.optionA <= optionA_max) then
           writeoutput;
       end;
   2 : begin
         if (rec^.optionA >= optionA_min) then
           writeoutput;
       end;
   3 : begin {invalid} end;
   4 : begin
         if (rec^.optionA >= optionA_max) then
           writeoutput;
       end;
[...]
   1316 : begin
            if (rec^.optionA >= optionA_min) AND
               (rec^.optionB >= optionB_min) AND
               (rec^.optionC >= optionC_min) AND
               {optionD not used in this one}
               (rec^.optionE >= optionE_min) then
              writeoutput;
          end;
[...]
   18506 : begin
             if (rec^.optionA <= optionA_max) AND
                (rec^.optionB >= optionB_min) and (rec^.optionB <= optionB_max) AND
                (rec^.optionC >= optionC_min) and (rec^.optionC <= optionC_max) AND
                (rec^.optionD >= optionD_min) AND
                (rec^.optionE >= optionE_min) then
               writeoutput;
           end;

the current idea is to use a bit for each "state" and then use a case statement 
for the "decision tree" (as shown above) so as to simply walk thru the integers 
that the bit patterns make for the valid combinations...

-- 
NOTE: No off-list assistance is given without prior approval.
       Please keep mailing list traffic on the list unless
       private contact is specifically requested and granted.