choice-metrics.com

Dear Ngene users,

I like to interact a dummy variable with a continuous variable. Furthermore, the dummy variable should have the same level across all alternatives in a choice situation.
I read the relevant chapters of the manual on "Efficient designs with interactions" (7.2.9) and "Designs within designs: Designs with scenarios in Ngene" (8.5).
You can see my current model below.

Code: Select all

Design
? This design will generate an efficient design for MNL model
;alts = a, b, c
;rows = 12
;eff = (mnl,d)
;cond:
if(a.D = 1, b.D = 1 and c.D = 1),
if(a.D = 2, b.D = 2 and c.D = 2),
if(a.D = 3, b.D = 3 and c.D = 3)
;model:
U(a) = b1[-0.000001] * C[1,2,3,4]        +
       b2.dummy[0|0] * D[1,2,3]          +
       i1[-0.000001] * C * D.dummy[1]    +       
       i2[-0.000002] * C * D.dummy[2]    /
U(b) = b1            * C                 +
       b2            * D                 +
       i1            * C * D.dummy[1]    +       
       i2            * C * D.dummy[2]    /
U(c) = b1            * C                 +
       b2            * D                 +
       i1            * C * D.dummy[1]    +       
       i2            * C * D.dummy[2]   
$


The continuous variable is C (in my case, a probability of an event), and the dummy variable is D (the event's intensity). From a theoretical point of view, I do not need the part "b2.dummy[0|0] * D[1,2,3]" in the utility functions as D has the same level across all alternatives in a choice situation. That is taken care of in the conditions. However, I cannot remove this part from the utility functions in Ngene because Ngene refers to it when I call the levels in the interactions. If I remove it, I get the error message "An attribute was specified with no levels, and was not previously defined. 'a.d'".
Therefore I decided to keep this part in the utility functions and set the parameters to zero to ensure that D does not affect utility.

I also tried to use "D[D]" in the utility functions of alternatives "b" and "c" (see chapter 8.5 of the manual) to signal that the level of D should be the same across alternatives. However, I get the error message "The level '1' specified in dummy or effects coded variable is not one of the levels of that attribute 'b.d'.". Therefore, I deleted "[D]" and included the conditions to ensure that D has the same level across the alternatives.

Is my approach the correct way of implementing my model in Ngene, or is there a more efficient way?

Kind regards
Andy Obermeyer

Hi Andy,

There is a little trick with which you can make attribute D "disappear" as a main effect in your model, see syntax below. I introduce attribute D in model m1 as a main effect, and once this variable is known in model m1, I can use it in model m2 as an interaction effect only. And then only optimise for the D-error for model m2. I think that this is what you are looking for?

Note that with so few attributes you may have dominant alternatives, so have a look at the choice tasks and see if they make sense (i.e., if there is not always one alternative that is better than others).

Code: Select all

Design
? This design will generate an efficient design for MNL model
;alts(m1) = a, b, c
;alts(m2) = a, b, c
;rows = 12
;eff = m2(mnl,d)
;cond:
if(a.D = 1, b.D = 1 and c.D = 1),
if(a.D = 2, b.D = 2 and c.D = 2),
if(a.D = 3, b.D = 3 and c.D = 3)
;model(m1):
U(a) = b1[-0.000001] * C[1,2,3,4]        +
       b2.dummy[0|0] * D[1,2,3]          /
U(b) = b1            * C                 +
       b2            * D                 /
U(c) = b1            * C                 +
       b2            * D                 
;model(m2):
U(a) = b1[-0.000001] * C[1,2,3,4]        +
       i1[-0.000001] * C * D.dummy[1]    +       
       i2[-0.000002] * C * D.dummy[2]    /
U(b) = b1            * C                 +
       i1            * C * D.dummy[1]    +       
       i2            * C * D.dummy[2]    /
U(c) = b1            * C                 +
       i1            * C * D.dummy[1]    +       
       i2            * C * D.dummy[2]   
$

Michiel

Dear Michiel,

Thank you very much for having a look at my model. The trick with the two models solves my problem. I also thank you for pointing out possible issues with dominant alternatives.

Kind regards
Andy