On 1/21/2014 10:21 AM, Mattias Gaertner wrote:
On Tue, 21 Jan 2014 09:51:38 -0500
waldo kitty <wkitt...@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
