Page 1 of 1

Nonconstant marginal utility

PostPosted: Fri Mar 27, 2009 10:06 pm
by miq
It is not quite clear to me if by specifying an attribute in utility function to be e.g.
Code: Select all
a1*A[0,1,2,3]
I assume that there will be a single parameter a1 for the attribute?

What I mean is: if I would like to have dummy-coded attribute levels (to allow for different marginal utilities of increases of its levels) is the above specification ok, or should I rather specify the utility function as:

Code: Select all
...
;cond:
if(alt1.A1=1,alt1.A2=0 and alt1.A3=0) ,
if(alt1.A2=2,alt1.A1=0 and alt1.A3=0) ,
if(alt1.A3=3,alt1.A1=0 and alt1.A2=0)

; model:
...
U(alt1)  = ... + a1*A1[0,1]+a2*A2[0,2]+a3*A3[0,3] + ... /
...


Am I right that in my case the second specifications is correct if I want to estimate separate parameters for all attribute levels?
Also, this second specification does not seem to work with orthogonal designs (conditions). How to work around it?

Re: Nonconstant marginal utility

PostPosted: Sat Mar 28, 2009 5:48 pm
by Andrew Collins
Ngene can natively handle dummy and effects coded attributes. Section 7.2.8 of the manual covers dummy and effects codes, and there is an example in the demonstration project. Your example would become:

Code: Select all
U(alt1)  = ... + a1.dummy[0|0|0]*A1[0,1,2,3] /


where the three zeros are the priors (which typically are specified as non-zero).

Note that dummy and effects codes are only relevant for efficient designs, where the priors specified for each level of the dummy or effects coded attribute will enter into the AVC matrix, and so affect the design efficiency. For an orthogonal design, the number of parameters that are to be estimated (more with dummy coding than a purely linear specification) should be considered when determining the degrees of freedom of the design and so the minimum number of rows, but it should not impact upon the orthogonality.

Re: Nonconstant marginal utility

PostPosted: Sun Mar 29, 2009 1:05 am
by miq
Thank you for this hint - I missed it in the manual.

.dummy did not seem to work with a reference scenario (which I tried to code using pivoted designs) so in this particular case I sticked with specifying conditions - I hope these methods are equivalent.
But the .dummy will be useful in the future anyway.