Ngene_questions

[Michiel Bliemer]

I generally use all parameter estimates as priors, even if they are not statistically significant, because it is still the best guess I have. And I use the standard error as the standard deviation in the normally distributed Bayesian prior to indicate that it is unreliable. But if the signs are unexpected then I would not use these priors and instead choose a conservative value with the correct sign. But it is really up to you.

A D-error of 4 is suspiciously high. That sounds almost like an unidentifiable model. Could you post the Ngene script so that I can have a look if something is wrong?

The Ngene app is Windows only, but it may be work under virtualisation software on a Mac, but we do not offer support for a Mac. We are working on a cloud based version of Ngene, which means that you can run Ngene in a browser on any computer, including a Mac. But that version is likely not ready until mid next year.

Michiel

[Sameh]

Dear Sir,

You will find the design with the new values of priors. Let me give you more explanations about the significance of theses coefficients, Price : significant, health :insignificant, BIO1 (HIGH LEVEL) : significant, BIO2 : significant, WQ1 (HIGH LEVEL) : significant, WQ2 : insignificant, RECR1 (high level) : significant, RECR2 : insignf, GAS1: significant , GAS 2 : insignf.
--------------------------------------------
design
alts = alt1*, alt2*, sq*
;rows = 18
;block = 3,minsum
;eff = (mnl,d)
;alg = mfederov

;require:
sq.WATER = 0,
sq.BIO = 0,
sq.RECR = 0,
sq.GAS = 0

;reject:
alt1.WATER + alt1.BIO + alt1.RECR + alt1.GAS = 1 and alt1.PRICE > 0,
alt2.WATER + alt2.BIO + alt2.RECR + alt2.GAS = 1 and alt2.PRICE > 0,
alt1.PRICE = 0 and alt1.WATER + alt1.BIO + alt1.RECR + alt1.GAS <> 1,
alt2.PRICE = 0 and alt2.WATER + alt2.BIO + alt2.RECR + alt2.GAS <> 1,

alt1.PRICE = 0 and alt1.HEALTH > 0,
alt2.PRICE = 0 and alt2.HEALTH > 0,
alt1.HEALTH = 0 and alt1.PRICE > 0,
alt2.HEALTH = 0 and alt2.PRICE > 0,

alt1.WATER = 0 and alt1.BIO = 2,
alt2.WATER = 0 and alt2.BIO = 2,
alt1.BIO = 2 and alt1.WATER = 0,
alt2.BIO = 2 and alt2.WATER = 0

;model :
U(alt1) = b1.dummy[0.17|0.624] * WATER[1,2,0]
+ b2.dummy[0.446|0.6] * BIO[1,2,0]
+ b3.dummy[-0.167|0.796] * RECR[1,2,0]
+ b4.dummy[-0.301|0.521] * GAS[1,2,0]
+ b5[-0.01] * HEALTH[0,25,50](0-18,6-12,6-12)
+ b6[-0.247] * PRICE[0,0.3,0.6,0.9,1.2,1.5](0-18,2-6,2-6,2-6,2-6,2-6) /


U(alt2) = b1 * WATER
+ b2 * BIO
+ b3 * RECR
+ b4 * GAS
+ b5 * HEALTH
+ b6 * PRICE
/

U(sq) = b_sq[0]
+ b1 * WATER
+ b2 * BIO
+ b3 * RECR
+ b4 * GAS
+ b5 * HEALTH_sq[0]
+ b6 * PRICE_sq[0]
$


----------------------------------
By conducting this pilote survey, I understood many things about the perception of the respondents and what should I modify in order to avoid biased scientific findings, I already have that clear. I wonder if I can neglect these results in can that if it will not provide us with realistic and useful informations that can refine the model.

I tried to compare each part : priced one (priced attribute) and the unpriced attributes to see how we can refine the results. I'm worried about the distribution of levels (here I'm talking about multiplying the price coefficient with its values that I indicated before as levels, about this point, I tried to understand more the idea by reading the article talking about : Choke price Bias in CE). I don't know if my doubts are seemed to be clear to you but I wonder if I can divide for example the price by 10 or 100 in order to adjust the Utility and the script (if it is permitted).

Have you any suggestions please ?

Greetings,
Sameh

[Michiel Bliemer]

Running the script results in a design with a D-error of around 0.4, not 4, so that looks perfectly fine.

Your prior for price looks reasonable for the price levels that you have, so I do not know why you want to divide the levels by 10 or 100. You can certainly do so, but then you have very small price levels and then there will not be much variation in the price attribute, making it difficult to estimate. If you divide all price levels by 10 you will see that the sample size estimate for b6, the price coefficient, becomes very large.

Michiel

[Sameh]

Dear sir,

Thanks for your response.

I don't know if you can see the previous EDIT [Edit Icon] thatI did in this conversation but I modified the script yesterday.

I proceed step by step, first at all, I tried to run the script by including just the significant coefficients and I left the rest (insignificant) as zero. The result was that the D-error was so extremely high.

When I received your last suggestions, I run the script by including both significant and insignificant coefficients (Same script but with the real value of price, 30, 60, 90, 120, 150), here the D-error is still too high and to my knowledge (this was the main question) it is so normal to obtain such results because the coefficient of the price is 0.247 and if we will multiply this value by these levels [30, 60, 90, 120, 150], here it can create a problem. I think that's why I asked you the question if I could divide the price by 10 or 100 (I talked above about multiplying the price levels by the price coefficient and the unpriced levels by their coefficients and then we proceed by comparing the values and I think that this is the point that led to obtaining a high d-error), what do you think? Is it reasonable what I say?

Then in another step, I refined the script (the last one that I published above) by dividing the price by 100 and when I had a new estimation with a more reasonable D.error value, I pressed the Edit icon of this conversation and I made a copy paste of the new script so that you can see it.

Thanks for being available to clarify my doubts.

Greetings,
Sameh

[Michiel Bliemer]

You need to use exactly the same price levels in the design as in model estimation. It does not seem possible that you estimate a parameter of 0.247 if your levels are 30 to 150. So there is some inconsistency somewhere, please make sure that the model and the attribute levels are identical in your Ngene syntax and in the data you use for model estimation.

Michiel

[Sameh]

Dear sir,

Please find the script attached:

design
alts = alt1*, alt2*, sq*
;rows = 18
;block = 3,minsum
;eff = (mnl,d)
;alg = mfederov

;require:
sq.WATER = 0,
sq.BIO = 0,
sq.RECR = 0,
sq.GAS = 0

;reject:

alt1.WATER = 0 and alt1.BIO = 2,
alt2.WATER = 0 and alt2.BIO = 2,
alt1.BIO = 2 and alt1.WATER = 0,
alt2.BIO = 2 and alt2.WATER = 0



;model :

U(alt1) = b1.effects[0.01|0.02] * WATER[1,2,0] + b2.effects[0.01|0.02] * BIO[1,2,0] + b3.effects[0.01|0.02] * RECR[1,2,0] + b4.effects[0.01|0.02] * GAS[1,2,0] + b5[-0.001] * PRICE[0,30,60,90,120](1-18,2-6,2-6,2-6,2-6)
/

U(alt2) = b1 * WATER
+ b2 * BIO
+ b3 * RECR
+ b4 * GAS
+ b5 * PRICE
/

U(sq) = b_sq[0]
+ b1 * WATER
+ b2 * BIO
+ b3 * RECR
+ b4 * GAS
+ b5 * PRICE_sq[0]
$


I wonder if you can explain to me why I'm receiving these warning messages when running the script :

Warning: One or more attributes will not have level balance with the number of rows specified: alt1.price, alt2.price
Warning: Two alternatives were specified for alternative repetition checking, but do not have the same attribute names, and so will not be checked. 'alt1', 'sq'
Warning: Two alternatives were specified for alternative repetition checking, but do not have the same attribute names, and so will not be checked. 'alt2', 'sq'

In my opinion,

About he first message : I think that logically is talking about the number of rows.

About second and third messages : I think that they are talking about specifying the price_sq as an attribute which does not exist in the first and second alternative specifications. is that the point ?

Another question concerning the output of the script attached : one of the alternatives in some choice sets is defined as a status quo (all levels = 0 , prix = 0), things that it hasn't to occur, have you any suggestion please ?

And finally, I know that this constrain (1-18,2-6,2-6,2-6,2-6) reflects the number of times that the attribute levels has to occur in order to avoid the extreme levels (price in my case). I don't know if the constrain that I put in the script is correct : (1-18,2-6,2-6,2-6,2-6) because I found many choice sets with extreme values (30-120).

And here I have an other question : if for example I have to change the rows to 24 (block = 3), is it right to define it like that : (1-24,2-8,2-8,2-8,2-8), is there a general rule about these instruction to be scripted ?

Greetings,

[Michiel Bliemer]

Yes you understand the warning messages correctly. These are not errors, merely warnings. Attribute level balance cannot be achieved with 18 rows if there are 5 price levels, but that is not a major issue. The other two warnings are not important and indeed refer to the fact that price_sq does not appear in the other alternatives.

Regarding attribute level constraints, if you have 18 rows with 5 price levels, then for perfect balance each level would need to appear 18/5 = 3.6 times, so you could have used (3-4,3-4,3-4,3-4,3-4). However, such strict constraints will make it very difficult for Ngene to find a feasible design that satisfies all these constraints, so relaxing it to (2-5,2-5,2-5,2-5,2-5) for example makes it easier. If you have 24 rows, then 24/5 = 4.8, so you could use constraints around approx 5 appearances for each level, e.g. (3-7,3-7,3-7,3-7,3-7). You can choose to not put constraints on one of the levels, such as 1-24 as you suggest.

A choice task captures more information if there are large trade-offs, i.e. by using the extreme attribute levels. Therefore, efficient designs usually result in more extreme attribute levels for numerical attributes when using the modified Federov algorithm, which is why attribute level constraints should be imposed. You can avoid this issue by dummy coding the price attribute when generating the design.

Michiel

[Sameh]

Dear sir,

Thanks for your responses and availability. My new script is as you will find below :

design
alts = alt1*, alt2*, sq*
;rows = 24
;block = 3,minsum,noimprov(20 secs)
;eff = (mnl,d,mean)
;alg = mfederov (stop=noimprov (2 mins))

;reject:

alt1.WATER = 0 and alt1.BIO = 2,
alt2.WATER = 0 and alt2.BIO = 2,
alt1.BIO = 2 and alt1.WATER = 0,
alt2.BIO = 2 and alt2.WATER = 0

;require :
alt1.WATER + alt1.BIO + alt1.RECR + alt1.GAS > alt2.WATER + alt2.BIO + alt2.RECR + alt2.GAS, alt1.PRICE > alt2.PRICE,
alt1.PRICE > alt2.PRICE, alt1.WATER + alt1.BIO + alt1.RECR + alt1.GAS > alt2.WATER + alt2.BIO + alt2.RECR + alt2.GAS,
alt2.WATER + alt2.BIO + alt2.RECR + alt2.GAS > alt1.WATER + alt1.BIO + alt1.RECR + alt1.GAS, alt2.PRICE > alt1.PRICE,
alt2.PRICE > alt1.PRICE, alt2.WATER + alt2.BIO + alt2.RECR + alt2.GAS > alt1.WATER + alt1.BIO + alt1.RECR + alt1.GAS


;model :
U(alt1) = b1.effects[0.01|0.02] * WATER[1,2,0] + b2.effects[0.01|0.02] * BIO[1,2,0] + b3.effects[0.01|0.02] * RECR[1,2,0] + b4.effects[0.01|0.02] * GAS[1,2,0] + b5[-0.001] * PRICE[30,60,90,120](2-6,2-6,2-6,2-6) /
U(alt2) = b1 * WATER + b2 * BIO + b3 * RECR + b4 * GAS + b5 * PRICE/
U(sq) = b_sq[(n,-0.10,0.05)]

I wonder if there's something wrong in the script (I should note that this has worked before ), I don't know why I'm receiving this error message :

" Error: The modified Federov candidate set size of 2000 could not be achieved. The percentages of candidates that failed are: 0% due dominance, 100% due constraints, and 0% due repeated alternatives. The candidate set size has been adjusted from 2000 to 0.

[Modified Federov] ERROR: The candidate set of the Modified Federov algorithm is smaller than the number of rows specified. That is, there are not enough unique choice sets to generate the number required as specificed in the ;rows property. This problem sometimes appears when there are too many reject and/or reject constraints.
Finished, at 9:54:18 AM, 11/29/2022 "

As I see, I think that the problem is posed by the conditions / restrictions. I know that it's a good thing to be faced to new error messages in order to learn what they are talking about but I'm trying to deal with the design also. So, here I have a question, I don't think that if I will put the require or reject in the same script, it can create a problem, right ?

Another question, normally I have 4 levels of price attribute : 30,60,90,120 (and the 0 as level of status quo). I tried in the script to not include the 0 to avoid it's appearance in the alternatives 1 and 2 (I can put a condition in order to tell the Ngene to not distribute it in alt1 and alt2), I wonder if it can be possible or not (I want to see from a Ngene programming point of view, how it will understand it ?)

Thanks for clarifying all my doubts,

Greetings,
Sameh

[Michiel Bliemer]

You can include both reject and require constraints, but the problem with your script is that you have imposed too many constraints and no design exists that satisfies all your constraints. You also imposed attribute level balance constraints (2-6,2-6,2-6,2-6) on price that does not make sense, this would need to be something like (4-8,4-8,4-8,4-8) if you have 24 rows. So you need to go carefully through all your constraints and make sure you only impose constraints that are necessary for realism purposes and relax others. As long as you do not dummy code price it is fine not to include level 0 for the price attribute in the first two alternatives. I notice that you have removed the attributes from the status quo alternative, but note that now Ngene is no longer able to check for dominant alternatives with respect to the status quo, I would therefore suggest that you revert back to my earlier proposed utility function for the status quo alternative.

Michiel