Relaxing some decision/utility node constraints

[jarrod-dalton]

1) I suggest we allow utility nodes to have children. In the below decision network, I create a child node of several utility nodes which is the sum of all the costs. I also create 'cost per outcome avoided' (CPOA), which I want to define simply as TotalCosts / OutcomesAvoided. We should allow this to happen.

2) I think we should allow decision nodes to a) be continuous (which will require some restrictive logic surrounding the functionality of policyMatrix(), compileDecisionModel(), etc.) and b) be defined deterministically (which suggests a sort of variant on our current maximum expected utility analysis where multiple networks (each of which might have different deterministic rules governing the decision node values given their parents) are compared on utility. For example, with the blackjack network, we might have one variant where the hit nodes are deterministically defined as 'hit if the is less than 14', another variant where the threshold is 15, and yet another where it is 16.

[jarrod-dalton]

I'm kinda/sorta changing my mind on the first relaxation I suggested, namely that utility nodes are allowed to have children. Below is from Koller & Friedman, and we should follow that convention.

However, I do think that we should do the second one, and I found a section in Koller & Friedman that discusses deterministic decision rules (last paragraph of Section 23.2.2 in the book):

[nutterb]

"These different node types are represented as ovals (chance), rectangles (decision), and diamonds (utility)."

Should I incorporate these shapes into the default plot options? The only one that would need to change is making utility nodes diamonds.

[jarrod-dalton]

This might be a good idea, if only to improve visualization when printed in b/w (something reviewers like to say but who prints stuff anymore?)

• Jarrod

On Oct 30, 2015, at 10:29 AM, Benjamin notifications@github.com wrote:

"These different node types are represented as ovals (chance), rectangles (decision), and diamonds (utility)."

Should I incorporate these shapes into the default plot options? The only one that would need to change is making utility nodes diamonds.

— Reply to this email directly or view it on GitHub.

[nutterb]

The good news is we have no restrictions on what variables may be decision nodes. The bad news is that defaultPolicyMatrix blows up when trying to reconcile numerical variables.

In the case when the node has data available, we could pull some set of values to include (P25, median, and P75?). The case where data are not available for the node is trickier and probably warrants an error when policyMatrix is called. That also means that there needs to be a way to pass the policy values in. I imagine we'd want a way to do that in both setNode and policyMatrix. So here is what I propose.

1. Add an argument policyValues=NULL to setNode. For categorical values, for numeric values, it populates an additional element that can be referenced later by 'policyMatrix'
2. In policyMatrix, add an argument useDefault = TRUE. This will allow a number of behaviors. So let's go through them.

The proposed function definition would be policyMatrix(network, useDefault = TRUE, ...)

The action of policyMatrix(network, TRUE) would be to produce the default policy matrix. If there is a numeric node with no policy values, it casts an error asking for policy values via the ... argument.

policyMatrix(network, TRUE, var1=[options]) would build the default policy matrix with the behaviors above and append any variables described in the .... If a variable in ... already exists as a decision node, the ... values override the default values.

policyMatrix(network, FALSE, var1=[options]) would only use the values in ... to build the policy matrix and ignore the default values specified in the model

Clear as mud, I'm sure. Thoughts, criticisms, and corrections are appreciated.

[jarrod-dalton]

1) should we create another tiny function setPolicyValues to handle the situation where the user runs setNode() without specifying that parameter and then remembers that they needed to set that parameter and doesn't want to call the function again, or is that overkill?

2) Should we disallow the use of policyValues when the decision node's nodeType is "determ"? By nature, the values of deterministic decision nodes can only be assigned by the values of its parent nodes. I suppose we can a posterori infer about the values of deterministic decison nodes' parents if we a) knew what the decision was and b) knew the function mapping the parents' values to the decision node values -- e.g., we saw that the player chose 'hit' and, given that the decision rule was "hit if the current point total is <17", we could probabilistically express beliefs about the current point total. It isn't clear to me a) whether or not this would be useful and b) whether or not we might run into trouble by allowing such things. (besides: with deterministic decision nodes, we would not really be using the policyMatrix() function anyways: instead, we'd be manually creating a list of HydeNetwork objects, each of which has their own deterministic function definitions for the decision nodes.)

3) Referencing comment #2 immediately above, should we restrict use of policyMatrix() and compileDecisionNetwork() to situations where all decision nodes are not deterministic?

On Fri, Oct 30, 2015 at 2:54 PM, Benjamin notifications@github.com wrote:

The good news is we have no restrictions on what variables may be decision nodes. The bad news is that defaultPolicyMatrix blows up when trying to reconcile numerical variables.

In the case when the node has data available, we could pull some set of values to include (P25, median, and P75?). The case where data are not available for the node is trickier and probably warrants an error when policyMatrix is called. That also means that there needs to be a way to pass the policy values in. I imagine we'd want a way to do that in both setNode and policyMatrix. So here is what I propose.

1.

Add an argument policyValues=NULL to setNode. For categorical values, for numeric values, it populates an additional element that can be referenced later by 'policyMatrix' 2.

In policyMatrix, add an argument useDefault = TRUE. This will allow a number of behaviors. So let's go through them.

The proposed function definition would be policyMatrix(network, useDefault = TRUE, ...)

The action of policyMatrix(network, TRUE) would be to produce the default policy matrix. If there is a numeric node with no policy values, it casts an error asking for policy values via the ... argument.

policyMatrix(network, TRUE, var1=[options]) would build the default policy matrix with the behaviors above and append any variables described in the .... If a variable in ... already exists as a decision node, the ... values override the default values.

policyMatrix(network, FALSE, var1=[options]) would only use the values in ... to build the policy matrix and ignore the default values specified in the model

Clear as mud, I'm sure. Thoughts, criticisms, and corrections are appreciated.

— Reply to this email directly or view it on GitHub https://github.com/nutterb/HydeNet/issues/95#issuecomment-152616148.

[nutterb]

1) overkill? maybe..but harmless.

2) I think it makes sense to disallow deterministic decision nodes from having policy values.

3) Would it be better to just force all policy values for deterministic nodes to be NULL. That is, require them to act deterministically?