constraints in Modified Federov Algorithm

[Nima Dadashzadeh]

Dear Ngene Team,

Below is a labeled design code that my student is developed for his study.

1. He would like to have constraints for the time (10,15,20,25) and cost (0,1000,2000,3000) of bike-sharing. This means whenever the time is 10, the cost should be 0, time = 15 and cost = 1000, time = 20 and cost = 2000, time = 25 and cost = 3000. The purpose is to see the willingness to use free-of-charge or paid services. However, the result is "undefined". If we delete one constraint (mentioned by ? in the code), then the Ngene is able to find a solution. In this case, we have a choice task including time = 10 and cost = 1000 which is not desired. Can we simply make cost = 0 in the result table for these choice tasks? or how we can solve this problem?

2. He also would like to add weather conditions as a scenario variable. The weather variable is only added to one utility function i.e. U(bike-sharing) as an interaction effect with travel time. Do we need to add it also to bike, U(bike)? If so, how?

Design
;alts = bikeshare, bike, car, taxi, bus, none
;rows=12
;alg = mfederov
;rdraws = Halton(1000)
;eff = (mnl,d)
;con

;reject:
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 15,
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 20,
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 25,
bikeshare.cost_bikeshare= 1000 and bikeShare.time_bikeshare= 10, ? for example we remove this line, Ngene is able to find a design.
bikeshare.cost_bikeshare= 1000 and bikeShare.time_bikeshare= 20,
bikeshare.cost_bikeshare= 1000 and bikeShare.time_bikeshare= 25,
bikeshare.cost_bikeshare= 2000 and bikeShare.time_bikeshare= 10,
bikeshare.cost_bikeshare= 2000 and bikeShare.time_bikeshare= 15,
bikeshare.cost_bikeshare= 2000 and bikeShare.time_bikeshare= 25,
bikeshare.cost_bikeshare= 3000 and bikeShare.time_bikeshare= 10,
bikeshare.cost_bikeshare= 3000 and bikeShare.time_bikeshare= 15,
bikeshare.cost_bikeshare= 3000 and bikeShare.time_bikeshare= 20,

bike.time_bike = 10 and bikeShare.time_bikeshare= 20,
bike.time_bike = 10 and bikeShare.time_bikeshare= 25,
bike.time_bike = 15 and bikeShare.time_bikeshare= 10,
bike.time_bike = 15 and bikeShare.time_bikeshare= 25,
bike.time_bike = 20 and bikeShare.time_bikeshare= 10,
bike.time_bike = 20 and bikeShare.time_bikeshare= 10


;model:

U(none) = ASC_none[n,0,0.5]
/

U(bikeshare)= ASC_bikeshare[n,0,0.5]
+ b_bikesharec[n,-0.00001,0.5]* cost_bikeshare[0,1000,2000,3000](1-10,3-10,3-10,2-10)
+ b_bikesharet[n,-0.00001,0.5]* time_bikeshare[10,15,20,25](1-10,3-10,3-10,2-10)
+ b_acc[n,-0.00001,0.5] * access[3,6,9](3-10,3-10,3-10)
+ b_weather[n,0,0.5] * time_bikeshare*weather[1,2,3,4](2-10,2-10,2-10,2-10)
/

U(bike) = ASC_bike[n,0,0.5]
+ b_biket[n,-0.00001,0.5] * time_bike[10,15,20](3-10,3-10,3-10)
/

U(car) = b_carc[n,-0.00001,0.5] * cost_car[8000,10000,12000](3-10,3-10,3-10)
+ b_ct[n,-0.00001,0.5] * time_car[12,14,16](3-10,3-10,3-10)
/

U(taxi) = ASC_taxi[n,0,0.5]
+ b_cost[n,-0.00001,0.5] * cost_taxi[3000,4000,5000,6000](2-10,2-10,2-10,2-10)
+ b_tt[n,-0.00001,0.5] * time_taxi[12,16,20](3-10,3-10,3-10)
+ b_acc * access
/

U(bus) = ASC_bus[n,0,0.5]
+ b_cost * cost_bus[1200,2000,2400](3-10,3-10,3-10)
+ b_bt[n,-0.00001,0.5] * time_bus[20,25,30](3-10,3-10,3-10)
+ b_acc * access

;formatTitle = 'Game <scenarionumber>'
;formatTableHeader = 'Imagine there is also bike-sharing system in the city, which option would you use to go to work&/study&?'
;formatTableFooter = '- Bike Sharing Cost&: The first 10 minutes of hiring a bike is free-of-charge, then you have to pay 1000&/extra 5 minutes. For example&: 15 minutes bike hire = 1000, 20 minutes = 2000 and 25 minutes = 3000.'

$

[Michiel Bliemer]

1. With the constraints you have created perfect correlation between time and cost and therefore you have created multicollinearity and therefore the model parameters are not identifiable, i.e. it is not possible to use this design for model estimation. If there is perfect correlation, then only the time parameter OR the cost parameter can be estimated, but not both. When you break the perfect correlation by removing one of the constraints then the model becomes identifiable.

2. In a labelled experiment you can add scenario variables as main effect and/or as interaction effect. It would probably make most sense to add weather as a main effect in both bike as well as bikeshare. Note that need to use dummy coding for weather, it cannot be just 1,2,3,4 as a linear effect. If you create an interaction effect, it means that you need to make interactions with multiple dummies, e.g. b_weather1 * time_bikeshare * weather.dummy[1].

Michiel

[Nima Dadashzadeh]

Dear Michiel,

Thank you for your prompt and helpful reply.

1. To avoid perfect correlation, we removed some of the constraints but keep some constraints to satisfy our aim to keep10 min bike share free of charge (cost=0) as follows:
;reject:
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 15, ? should pay for riding more than 10 min => time > 10, cost should not be 0
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 20,
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 25,
bikeshare.cost_bikeshare= 1000 and bikeShare.time_bikeshare= 10, ? should not pay for 10 min => time = 10, cost =0
bikeshare.cost_bikeshare= 2000 and bikeShare.time_bikeshare= 10,
bikeshare.cost_bikeshare= 3000 and bikeShare.time_bikeshare= 10

;require:
bike.time_bike >= car.time_car, ? bike riding time should be equal to or larger than CAR travel time
bike.time_bike <= bus.time_bus, ? bike riding time should be equal to or less than BUS travel time
bikeShare.time_bikeshare <= bus.time_bus ? bikeshare riding time should be equal to or less than BUS travel time

2. Regarding “weather as a main effect variable”, could you please clarify how we can implement it in bike and bikeshare utility functions ?
Weather attribute levels are 1=Good, 2=Windy, 3=Rainy, 4=Snowy

Kind regards,
Nima

[Michiel Bliemer]

You could include scenario variable 'weather' as follows:

;require:
bikeshare.weather = bike.weather

;model:
U(bikeshare)= ASC_bikeshare
+ b_bikesharec * cost_bikeshare[0,1000,2000,3000](1-10,3-10,3-10,2-10)
+ b_bikesharet * time_bikeshare[10,15,20,25](1-10,3-10,3-10,2-10)
+ b_acc * access[3,6,9](3-10,3-10,3-10)
+ b_weather.dummy[0|0|0] * weather[2,3,4,1] ? 1=Good, 2=Windy, 3=Rainy, 4=Snowy
/
U(bike) = ASC_bike
+ b_biket * time_bike[10,15,20](3-10,3-10,3-10)
+ b_weather * weather

Another comment: I would strongly recommend against specifying a model with random parameters as you current have with [n,mean,stdev]. You could consider Bayesian priors using [(n,mean,se)] but your se cannot so large as 0.5 if you have huge attribute levels for cost etc, that will ruin your entire efficient design. I would use all zero priors until you have estimated a model using pilot study data.

Michiel

[Nima Dadashzadeh]

Dear Micheil,

Thank you for your helpful comments.

This study will NOT have a pilot data collection stage.

So, in this case, do you mean we should use se=0 like [n, -0.00001, 0] or we could not have Bayesian D-efficient design at all and we should have D-efficient design using simply [-0.00001] for parameters that we know the sign and [0] for parameters that we do not know the sign?

[Michiel Bliemer]

You should NOT use [n,-0.0001, 0] because that indicates a mixed logit model with random parameters. You could use Bayesian priors such as [(n,-0.0001,0)] or [(u,-0.5,0.5)], see my previous message.

Using a small positive or negative prior is only useful when avoiding dominant alternatives in an unlabelled experiment. In a labelled experiment such as this, -0.00001 will not really be any different from 0.

[Nima Dadashzadeh]

Dear Micheil,

Many thanks for your time and reply. So, this is the latest form of the code. Is that ok now?
- we also add also attribute balance level for the weather to see less snowy weather.

;alts = bikeshare, bike, none
;rows=12
;alg=mfederov(stop = noimprov(3600 secs))
;bdraws = Halton(1000)
;eff = (mnl,d)
;con

;reject:
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 15,
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 20,
bikeshare.cost_bikeshare= 0 and bikeShare.time_bikeshare= 25,
bikeshare.cost_bikeshare= 1000 and bikeShare.time_bikeshare= 10,
bikeshare.cost_bikeshare= 2000 and bikeShare.time_bikeshare= 10,
bikeshare.cost_bikeshare= 3000 and bike share.time_bikeshare= 10

;require:
bikeshare.weather = bike.weather,

;model:

U(none) = ASC_none[(n,0,0)]
/

U(bikeshare)= ASC_bikeshare[(n,0,0)]
+ b_bikesharec[(n,0,0)] * cost_bikeshare[0,1000,2000,3000](1-10,3-10,3-10,2-10)
+ b_bikesharet[(n,0,0)] * time_bikeshare[10,15,20,25](1-10,3-10,3-10,2-10)
+ b_acc[(n,0,0)] * access[3,6,9](3-10,3-10,3-10)
+ b_weather.dummy[0|0|0] * weather[2,3,4,1] (3-10,3-10,1-10,3-10) ? attribute balance level for the weather to see less snowy weather and more good, windy, and rainy weather among choice sets.
/

U(bike) = ASC_bike[(n,0,0)]
+ b_biket[(n,0,0)] * time_bike[10,15,20](3-10,3-10,3-10)
+ b_weather * weather

[Michiel Bliemer]

The comma in the require property should be removed, but other than that I think it looks fine. Note that (n,0,0) is identical to 0, so I would replace it with value 0 to avoid confusion with Bayesian priors.