choice-metrics.com

Hello,

I am very new to DCEs and Ngene and just wanted to check I’m on the right track with my orthogonal design.

We have 2 unlabelled alternatives and a status quo (opt-out) option; and six attributes with 2 or 3 levels. Based on the number of parameters to estimate I thought that 8 sets with no blocks would have been suitable but when this syntax is run I am getting an error message “Warning: One or more attributes will not have level balance with the number of rows specified: alt1.b2, alt2.b2
[Orthog] Could not locate design in 8 rows. Switching to design with 36 rows.”
Hence revised the syntax to the below with 4 blocks and 36 rows. Does this seem appropriate?
Or alternatively could revise the ‘time’ attribute to 2 levels (hence all attributes would have 2 levels) to have a design with 2 blocks and 16 rows.

With the 36 row design I am getting a choice where both alternatives are the same (row 1) and a dominant alternative (row 34). Is there a way to avoid these choices? I have read about adding a ‘*’ after ‘alt1’ and ‘alt2’ but doesn’t seem to make a difference. Is there something I am missing?

?ORTHOGONAL DESIGN
Design
;alts = alt1, alt2, SQ
;block = 4
;rows = 36
;orth = sim
;con
;model:

U(alt1)=Cost.effects[0]*b1[0,1]+Time.effects[0|0]*b2[0,1,2]+Child.effects[0]*b3[0,1]+Coparent.effects[0]*b4[0,1]+Friend.effects[0]*b5[0,1]+Foodtype.effects[0]*b6[0,1]/
U(alt2)=Cost.effects *b1 +Time.effects *b2 +Child.effects *b3 +Coparent.effects *b4 +Friend.effects *b5 +Foodtype.effects *b6/
U(SQ)=b7[0]$

We are trying to keep the number of sets down as we have two different scenario contexts (with the same design) to present to participants.

Any advice or guidance would be greatly appreciated!
Britt

Hi Britt

The problem you have encountered occurs due to b2[0,1,2]. All the other attributes have 2 levels.

A design is orthogonal if each pair of levels occurs an equal number of times across all pairs of attributes. When each attribute of the design has an equal number of levels, a design that is orthogonal under the above definition is called an orthogonal array. When different attributes have different numbers of levels, the resulting design is termed a mixed array design. By having a mix of attributes with 2 and 3 levels, you have a mixed array.

Now, given the above definition, all three levels of b2 must at a minimum appear an equal number of times in 8 rows. Unfortunately, 8 is not divisible by 3 without remainder, hence there cannot exist an orthogonal design for this problem in 8 rows. The smallest design in which 2 and 3 levels can occur an equal number of times without remainder is 12 - that is 12 rows. Whilst an orthogonal design exists for 12 rows with 3 and 2 levels, you cannot use this design.

The problem is that you want orthogonality to be maintained across all columns of the design irrespective of the alternative (orth = sim) - as you have 6 attributes per alternative and 2 alternatives, you actually have 12 design columns all of which you want to be orthogonal. The orthogonal design in 12 rows has 4 columns with 3 levels and only 1 with 2 levels. You want 2 columns with 3 levels and 10 with 2 levels - the smallest orthogonal design Ngene could find that matches your requirements has 36 rows.

This is not a problem with Ngene, but rather with orthogonal designs. They exist only for a set number of orthogonal designs, so if you want an orthogonal design, you often have to change your expectations, as here.

If you still want orthogonality, then you have done the right thing - you need to block it. The other approach is to let go of orthogonality and use an efficient design. That you can do in 8 rows.

Code: Select all

Design
;alts = alt1*, alt2*, SQ
;rows = 8
;eff = (mnl,d)
;model:
U(alt1)=Cost.effects[0]*b1[0,1]+Time.effects[0|0]*b2[0,1,2]+Child.effects[0]*b3[0,1]+Coparent.effects[0]*b4[0,1]+Friend.effects[0]*b5[0,1]+Foodtype.effects[0]*b6[0,1]/
U(alt2)=Cost.effects *b1 +Time.effects *b2 +Child.effects *b3 +Coparent.effects *b4 +Friend.effects *b5 +Foodtype.effects *b6/
U(SQ)=b7[0]$

The other issue you have discovered regarding orthogonal designs is that orthogonality is purely a mathematical property (defined above for you - "each pair of levels occurs an equal number of times across all pairs of attributes"). This property says nothing about dominance, just the number of times attribute pairs occurs. Again, letting go of orthogonality may solve this, but I understand some people still want to use orthogonal designs. In such cases, you have to simply wear it. There maybe some tricks you can try however. You can rotate the levels for one or more attributes (a 0 becomes a 1 and a 1 a 0 down an entire column). This may break the dominance, but it may also break orthogonality so I suggest you check.

Good luck with the project.

John

Hi John,
Thank you for your quick response!
We don't have any prior estimates etc which is why I was thinking orthogonal. Will look into revising the attribute levels so that we don't have a mixed array, or consider swapping to an efficient design.
Greatly appreciated,
Britt

Hi Britt

Understood. Please note however that the assumption that beta = 0 is technically a prior, no different to assuming beta = 1 or beta = -1. Your optimising the design for a very specific value, which is akin to stating that you believe the true population parameter is that value (zero in your case).

Note that this is different to having uncertainty about what the true population parameter is (i.e., it could be 1, 0 or -1, you just don't know - see this is different to saying it IS 0). We handle uncertainty about population parameters using Bayesian priors (e.g., b1[(u,-1,1)] which states that the true parameter could be between -1 and 1 drawn from a Uniform density).

Also, even if you wish to assume beta = 0 (nothing wrong with this assumption - its an assumption like any other), you can still optimise the design with this prior in mind. As I said originally, beta = 0 is no different theoretically than beta = 1 or -1. Plus, you can also optimise orthogonal designs (you keep the orthogonality constraint) and still generate an efficient design.

John

Hi John,

What a great idea with the uniform distribution. Thanks for that inspiration!
I just tried to implement the b1[(u,-1,1)] to my syntax and it works pretty fine, but it shows that the design has high d-efficiency values (e.g. 0.108). I also tried to use effects-coding with this formula e.g. b1.effects[(u,-1,1)], but Ngene replies "Error: An attribute has the wrong number of levels for dummy or effects coding". Is there any possibility to align your approach with the effects/dummy coding?

Thanks a lot for your help!

Best,
Boris

Note that the value of D-error itself has no meaning. In some cases, a value of 0.1 is very good while in other cases is it not very good. For the priors specified, the smaller the D-error the better, but you cannot compare D-errors when using a different utility specification and different priors.

You can use Bayesian priors in the same way for dummy/effects coded variables by specifying a prior for all levels (except for the reference level). For example, b[(u,-1,1)|(u,-1,1)]*x[1,2,0].

Michiel