3

I've developed a program which generates insurance quotes using different types of coverages based on state criteria. Now I want to add the ability to specify 'rules'. For example we may have 3 types of coverage (we'll call them UM, BI, and PD). Well some states don't allow PD to be greater than BI and other states don't allow UM to exist without BI. So I've added the ability for the user to create these rules so that when the quote is generated the rule will be followed and thus no state regulations will be violated when the program generates the quote.

The Problem

I don't want the user to be able to select conflicting rules. The user can select any of the VB mathematical operators (>, <, >=, <=, =, <>) and set a coverage on either side. They can do this multiple times (but only one at a time) so they might end up with a list of rules like this:

  • A > B
  • B > C
  • C > A

As you can see, the last rule conflicts with the previously set rules. My solution to this was to validate the list each time the user clicks 'Add rule to list'.

Pretend the 3rd list item is not yet in the list but the user has clicked 'add rule' to put it in the list. The validation process first checks to see if both incoming variables have already been used on the same line. If not, it just searches for the left side incoming variable (in this case 'C') in the already created list. if it finds it, it then sets tmp1 equal to the variable across from the match (tmp1 = 'B'). It then does the same for the incoming variable on the right side (in this case 'A'). Then tmp2 is set equal to the variable across from A (tmp2 = 'B'). If tmp1 and tmp2 are equal then the incoming rule is either conflicting OR is irrelevant regardless of the operators used. I'm pretty sure this is solid logic given 3 variables. However, I found that adding any additional variables could easily bypass my validation. There could be upwards of 10 coverage types in any given state so it is important to be able to validate more than just 3.

Is there any uniform way to do a sound validation given any number of variables? Any ideas or thoughts are appreciated. I hope my explanation makes sense. Thanks

Deanna
  • 23,876
  • 7
  • 71
  • 156
user1457296
  • 239
  • 1
  • 3
  • 8
  • That's going to be painful to model in something as limited in it's power of expression as VB6. A couple of tips. Split the rules between equality ( = and <>) and the relataional operators. For the relations rearrange so only one operator is used e.g. < At that point you have an order B < C < D so adding A < B without breaking the order will work, but trying to add D < B will. Good question though! – Tony Hopkinson Jul 03 '12 at 23:11
  • This was my first thought but then I realized that I don't always know the order given the rules. I might know that C and A are both greater than B but the value of C in relation to A could still be ambiguous. This really only becomes a problem when I introduce more than 3 variables. – user1457296 Jul 05 '12 at 15:17
  • Nothing you can do about that, aside from having different lists of rules you can relate. – Tony Hopkinson Jul 06 '12 at 10:15

2 Answers2

1

My best bet is some sort of hierarchical tree of rules. When the user adds the first rule (say A > B), the application could create a data structure like this (lowerValues is a Map which the key leads to a list of values):

lowerValues['A'] = ['B']

Now when the user adds the next rule (B > C), the application could check if B is already in a any lowerValues list (in this case, A). If that happens, C is added to lowerValues['A'], and lowerValues['B'] is also created:

lowerValues['A'] = ['B', 'C']
lowerValues['B'] = ['C']

Finally, when the last rule is provided by the user (C > A), the application checks if C is in any lowerValues list. Since it's in B and A, the rule is invalid.

Hope that helps. I don't remember if there's some sort of mapping in VB. I think you should try the Dictionary object.

In order to this idea works out, all the operations must be internally translated to a simple type. So, for example:

A > B

could be translated as 

B <= A

Good luck

Deanna
  • 23,876
  • 7
  • 71
  • 156
Robson França
  • 661
  • 8
  • 15
  • True, the dictionary would be a good alternative to what I'm doing now...but how exactly would that hold up for 4 variables? (* A >= B * B <= C * C > D * D = A ) 'D' would not be in the dictionary under 'A' so this would bypass the validation but it is a conflict. I do like the idea of translating the symbols...that might open a few more possibilities – user1457296 Jul 03 '12 at 22:48
  • Well D would already be in lower[A] so you could detect the conflict there - you might need a equals[] / notequals[] to keep track of those operations - @Robson - like your idea but it needs more work to flesh out the = and <> – DJ. Jul 04 '12 at 00:56
1

In general this is a pretty hard problem. What you in fact want to know is if a set of propositional equations over (apparantly) some set of arithmetic is true. To do this you need what amounts to constraint solvers that "know" arithmetic. Not likely to find that in VB6, but you might be able to invoke one as a subprocess.

If the rules are propositional equations only over inequalities (AA", write them only one way). Second, try solving the propositions for tautology (see for Wang's algorithm which you can likely implment awkwardly in VB6).

If the propositions are not a tautology, now you want build chains of inequalities (e.g, A > B > C) as a graph and look for cycles. The place this fails is when your propositions have disjunctions, e.g., ("A>B or B>Q"); you'll have to generate an inequality chain for each combination of disjunctions, and discard the inconsistent ones. If you discard all of them, the set is inconsistent. Watch out for expressions like "A and B"; by DeMorgans theorem, they're equivalent to "not A or not B", e.g., "A>B and B>Q" is the same as "A<=B or B<=Q". You might want to reduce the conditions to disjunctive normal form to avoid getting suprised.

There are apparantly decision procedures for such inequalities. They're likely hard to implement.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341