conditions and rejections

[Sanchez]

Hello.

In my current experimental design, there are a number of constraints I need to incorporate into the design.
I am using the ;cond: command a lot and everything is working, my problem now is that I get alternatives which exactly match the status quo (where all alternatives are equal to zero).
Is there any way I can prevent this?

I have tried to use the ;reject: command as below, but I can't seem to get it to work:

;reject:
X.BMP = X.Reb = X.Mech = X.Pay = X.Env = [0],
Y.BMP = Y.Reb = Y.Mech = Y.Pay = Y.Env = [0]

I also tried it without putting the zero above in brackets, but without success.
Any suggestions?

[johnr]

Hi Sanchez

Can you please post or email us the entire syntax

Thanks John

[Sanchez]

Hi John.

Sure! Thanks for getting to this so quickly. Below is the code without the ;reject: included. The last condition already addressed the issue where an alternative had the same levels as the status quo, but a better environmental condition and so clearly dominated the status quo.

Thanks again!

Code: Select all

Design
;alts = X*, Y*, sq
;rows = 24
;eff= (mnl, d)
;block = 3

;cond:
? NECESSARY CONDITIONS:
? If no Private BMP (BMP), can’t get a rebate (Reb)
If (X.BMP=0, X.Reb=0),
If (Y.BMP=0, Y.Reb=0),
? If no Payment Mechanism(Mech) in place, can’t have a cost to the Payment mechanism(Pay)
If (X.Mech=0, X.Pay=0),
If (Y.Mech=0, Y.Pay=0),
? If have a Payment Mechanism(Mech), need cost of Payment mechanism(Pay)to be larger than zero
If (X.Mech>0, X.Pay>0),
If (Y.Mech>0, Y.Pay>0),
? If no Payment Mechanism(Mech) in place, can’t rebate(Reb)
If (X.Mech=0, X.Reb=0),
If (Y.Mech=0, Y.Reb=0),
? If have Payment Mechanism (Mech) in place, can't have Env cond staying current
If (X.Mech = [1,2,3,4], X.Env = [1,2]),
If (Y.Mech = [1,2,3,4], Y.Env = [1,2]),

?Don't want to have dominated alternative by having env improvement without anything.
If (X.BMP = 0 and X.Mech = 0, X.Env=0),
If (Y.BMP = 0 and Y.Mech = 0, Y.Env=0)

;model:
U(X) = 
b1.effects [-0.05|-0.07|-0.09]* BMP [1,2,3,0] + 
b2[0.3]* Reb[0,25,50,75] + 
b3.effects [-0.1|-0.1|-0.1|-0.1]* Mech [1,2,3,4,0] + 
b4[-0.15] * Pay[0,36,60,108] + 
b5.effects [0.05|0.1] * Env [1,2,0] /
U(Y) = b1* BMP + b2 * Reb + b3*Mech+ b4*Pay +b5*Env
$

[Andrew Collins]

Hi Sanja

First, the correct way to specify this condition with the reject property would be:

Code: Select all

;reject:
X.BMP=0 and X.Reb=0 and X.Mech=0 and X.Pay=0 and X.Env=0

However, the reject property requires the modified federov algorithm, while the cond property is incompatible with the modified federov algorithm, so the two can't be specified together.

Running the syntax you provided, I don't find many situations where and alternative has all zeros (i.e. is the same as the status quo). Perhaps you could just check the final design, and discard designs until you find one that doesn't violate that condition? If the incidence rate is low, you shouldn't need to throw away many, and chances are that there is only a very small difference in design performance. Consider specifying ;store=50, which will keep more of the most recent designs in memory than the default 10.

Andrew

[Sanchez]

Hi Andrew.
I tried what you suggested, but even in the last 50 designs, there is always at least one case where the status quo option is reflected in one of the alternatives.
Is there no other way to do this? Do you have any other ideas?
Thanks a lot for your assistance - much appreciated.

[Andrew Collins]

Hi Sanja

The best that I can suggest is to save the design matrix of the best design (with the problem alternatives) to a csv or Excel file. You can evaluate the design by reading it in with the ;eval property (see the manual for details). Then, make manual adjustments to the levels of the problem choice alternatives, that don't violate the rules you have specified (or, as few as possible). Try various adjustments, and see which has the lowest d-error with the eval property.

Basically, you are exhausting the constraints functionality in Ngene. We plan to make this even more flexible going into the future, as we know that it is a widely used feature.

Andrew