Possible to combine level frequency constraints and cond?

This forum is for posts that specifically focus on the Windows desktop version of Ngene (i.e. all version 1.x releases).

Moderators: Andrew Collins, Michiel Bliemer, johnr

Post Reply
rich_imr
Posts: 12
Joined: Wed Oct 21, 2015 2:52 am

Possible to combine level frequency constraints and cond?

Post by rich_imr »

Greetings,

Is it possible to combine attribute level frequency and logical cond constraints?

An example could be, for attribute 1 levels 1-4, attribute 2 level 1 appears 80% of the time and attribute 2 level 2 appears 20% of the time.

I did see that this post "Conditions and attribute level balance" says it is not possible, but I wanted to make sure since it was from 2011.

Are there any workarounds?

Thank you very much for your time,

Richard
Michiel Bliemer
Posts: 2057
Joined: Tue Mar 31, 2009 4:13 pm

Re: Possible to combine level frequency constraints and cond

Post by Michiel Bliemer »

Short answer: No it is not possible to combine ;cond with the default swapping algorithm.

Long answer:

There exist two main algorithms in Ngene, namely (i) a column based swapping algorithm that can always ensure attribute level balance but that cannot handle complex constraints, and (ii) a row based modified Federov algorithm that can handle more complex constraints but cannot guarantee attribute level balance. Each algorithm is designed to work with certain constraints. The swapping algorithm works with ;cond constraints, while the modified Federov algorithm works with ;require and ;reject constraints. It is not possible to combine ;cond and ;require/;reject because the way the algorithms work.

There may be a workaround. It is sometimes possible to reformulate the ;cond constraints into ;reject or ;require constraints. This may require a bit of creativity (maybe I can help) and then use the modified Federov algorithm for which you can set upper and lower bounds on the frequency each attribute level appears (i.e. the degree of attribute level balance).

Michiel
Post Reply