dominant alternatives

[Michela]

Good morning,

I am writing you concerning one problem of dominant alternatives that I encountered in the development of the orthogonal design that I will employ for the pilot study of my project. In principle, by using the command * after listing the alternatives in the Ngene instructions, the program should automatically avoid generating -among other things- strict attribute level dominance. Is "strict attribute level dominance" the same as "dominant alternatives"? How could I solve the presence of some dominant alternatives in the design: by manually changing at least the level of one attribute for one of the alternatives so as it is no longer dominant? By deleting the choice card displaying dominant alternatives? Or is there another way to handle with this problem, given the design has already been generated?

Regards,

Michela

[johnr]

Hi Michela

Strict attribute level dominance is where the attributes of one alternative are all 'better' than another, so this is the same as having a dominated alternative.

One problem with using an orthogonal design is that it may not be possible to avoid dominated alternatives. This is because orthogonality is a mathematical constraint you are placing on the level combinations over the design, and that constraint may make it impossible to remove dominance in all choice tasks. This is one of the advantages of using an efficient design, where you let go of the orthogonality constraint. Note that if you manually change the levels of the design, then you are going to loose orthogonality. So if orthogonality is an important criterion for you then you should not do this, however if you don't do it, then you will end up with dominated alternatives in your case. Orthogonality is also about independence of the columns of the design. Hence, you can remove columns (attributes), however deleting rows (which is commonly done in the literature unfortunately) will change the attribute level combinations displayed over the design. Again, this will mean a loss of orthogonality. You therefore need to consider what is more important to you, orthogonality or dominated alternatives. If the later, then you would be better off generating an efficient design in the first place, however if you have an orthogonal design already, then removing the dominated tasks, or manually changing the tasks is probably better than having dominated alternatives which can result in econometric issues (scale effects, model separation)/

John

[Michela]

Hi John,

everything clear! Many thanks!

Just to be sure I understood how to handle with dominanted alternatives in efficient designs: I will soon develop a d-efficient for my final survey - the orthogonal design is just for the pilot survey to collect priors' information - and I would like to make sure that no dominanted alternatives are present. Will I be perfectly able to avoid them by introducing the * command? Will the program avoid dominated alternatives in any circumstances in d-efficient designs or is a further supervision of the generated alteratives advisable to check that none is dominant?

Best regards,

Michela

[johnr]

Hi Michela

Glad we can help. You are correct in your post. The* in the ;alts = A*,B*, ... command is designed to reduce or remove dominance within the design. It will only really be effective if you have non-zero priors for your design however. You should always check the design in any case to be sure that it has worked properly. Michiel and I typically use the formatted scenarios option to display the choice tasks in a manner that makes it easier to see what respondents will see rather than look at a matrix and try and decipher what they will see.

Best of luck with your study.

John

[Michela]

Thank you very much again!

Best regards,

Michela

[julian]

Hi there,

I would just like to add a point to curing the problem of dominant alternatives in orthogonal designs and then pose a question concerned with blocking using the eval Option.

1. There are at least two ways to reduce the number of dominant alternatives. First you may change the order of columns, i.e. the first attribute of alternative A will be swapped with the first attribute of alternative B. Second, you may recode or relabel your levels. If your attribute is coded 0 1 2 and 2 is the best, you can reverse the order so that 2 is the worst. Both will not affect orthogonality.
However, - please correct me if I am wrong - NGene would not do this (even when specifing priors). I have recently created an orthogonal design (orth=sim) and found 8 dominant alternatives. Only by changing the columns I could reduce it to two.
It was little bit tricky to do this swapping. I wrote a code in STATA that tried out all column combinations and reported the number of dominated alternatives. I then saved the design with the lowest number of dominant alternatives and read it into NGene via ;eval to use the html formatting capabilities. Accept for the problem reported below, it worked very well.

2. While reading the new design with ;eval, NGene overrid the old blocking and assigned new blocks, using some algorithm to minimize the correlation. BUT, somehow, it assigns Blocks that do not have zero correlation as the initial design had. Hence I am wondering what happened here and why it is not possible to use/read the old blocking variable? My cure here was to pretend the block is another attribute of the last alternative, but this is not very elegant.

Thanks for an answer! I hope it makes sense what i was doing here!

Kind Regards,

Julian

[Michiel Bliemer]

Hi Julian,

1. You are right, you can always swap columns and relabel attribute levels and maintain orthogonality. Ngene uses such techniques to search for efficient orthogonal designs, i.e. when using both ;orth and ;eff = (mnl,d). However, when aiming for non-dominancy, Ngene rejects a design when one or more alternatives are dominant. In your case you are minimising the dominancy, while Ngene is looking for a design without any dominancy. Clearly, you do not want any dominant alternatives in your design, as this will be problematic in estimation and these questions will not provide you with much information. Why holding on to orthogonal designs and not go for an efficient design that can get rid of dominant alternatives? I can understand that it would be possible to minimise the dominancy instead of reject is, and this could be a future feature of Ngene, but I do not think that anyone should use such a design that still contains dominant alternatives.

2. When generating orthogonal designs, Ngene creates blocking columns using orthogonal arrays and can therefore guarantee no correlations. When reading in an unknown design, Ngene aims to find a blocking column that tries to minimise correlations as much as possible (but it may be difficult to find). I think you may be correct that currently Ngene does not read in the blocking column, which is indeed something that would be useful. I will consult with my co-developers, but this should indeed be possible and we will implement it in a next release.

[Andrew Collins]

Just letting you know that the next point release will indeed preserve the existing blocking column. There will also be an option to generate a new column when the existing design is evaluated (perhaps to improve the blocking, change the number of blocks etc), but this will not be default behaviour. It will also fix a problem that limited the maximum run time for blocking generation. The 1.1.2 point release will be up very shortly now, I'm hoping in the next week.

Andrew