Nested Logit - fixed lambda (NNNL vs. UMNL)

bartosz · Post by **bartosz** » 21 Dec 2021, 18:41

I am working on a tour-based model for transport mode choice, and want to use Nested Logit to replicate the relationship between tour complexity and mode choice, as shown below:

: NL structure.png (5.04 KiB) Viewed 5285 times

Given that I have two nests, there are two nesting parameters *lambda* to be estimated - lambda_simple and lambda_complex.

However, I am a bit confused about how to specify them in the model. Hensher & Reyes (2000), for an identical case, fixed one of the inclusive value parameters to 1.0, which is not really clear for me why. May it have to do with the software they used and the two alternative implementations of Nested Logit that exist in many packages:

non-normalized nested logit (NNNL) by Daly (1987; 2001)
and utility maximizing nested logit (UMNL) advocated by Koppelman & Wen (1998) ??

Is it the normalization "trick" that they used possibly due to the software they used or what could be the reason for that?

From section 5.1.1 of Apollo manual and from the examples, I would conclude that Apollo employs the UMNL form, which does not need any further normalizations, but I am still a bit confused.

Thus, I would have following questions:

which NL form is implemented in Apollo: NNNL or UMNL?
is a normalization of one of the lambdas needed in NL in Apollo?
even if it is not needed, what would it change in the estimation and interpretation of the other lambdas and the coefficients, should I fix one of the lambdas to = 1.0?

I would appreciate if you could clarify it a little. Thank you for your time!

Bartosz

Post by **stephanehess** » 03 Jan 2022, 15:55

Bartosz

Apollo uses the normalised NL model, but that's not the point in this context (as even in the ALogit version you do not need to fix one lambda to 1).

The role of the lambda parameter is to explain differences in the error variances for choices between alternatives within a nest in contrast with choices between alternatives in different nests. You could thus estimate lambdas both for simple and complex, given that you still have the root lambda fixed to 1.

Fixing the lambda in one nest to 1 is the approach that people used to use when combining data from different sources to understand differences in error variance (e.g. RP vs SP), but with software that allows for non-linear utilities like Apollo, you can just do this within MNL.

Now what's not clear to me is whether your alternatives in different nests are available at the same time. If not, then you would not be able to estimate all the lambdas as you would not have any choices between alternatives in different nests

Stephane

bartosz · Post by **bartosz** » 05 Jan 2022, 11:21

Stephane, thank you for clarifying the issue of normalizing the lambdas and NL versions.

The reason I was concerned about this fixing of one of the lambdas to 1 was because:

without fixing, I obtain absolutely crazy results:

Code: Select all

Model name                       : TNL_1.1_summer
Model description                : Tour-based NL model with TT + COST generic. Nesting: simple vs. complex
Model run at                     : 2022-01-05 12:09:24
Estimation method                : bfgs
Model diagnosis                  : successful convergence 
Number of individuals            : 289
Number of rows in database       : 511
Number of modelled outcomes      : 511

Number of cores used             :  1 
Model without mixing

LL(start)                        : -679.7981
LL(0)                            : -679.7981
LL(C)                            : -508.264
LL(final)                        : -416.8293
Rho-square (0)                   :  0.3868 
Adj.Rho-square (0)               :  0.3707 
Rho-square (C)                   :  0.1799 
Adj.Rho-square (C)               :  0.1583 
AIC                              :  855.66 
BIC                              :  902.26 

Estimated parameters             :  11
Time taken (hh:mm:ss)            :  00:00:11.92 
     pre-estimation              :  00:00:0.22 
     estimation                  :  00:00:10.18 
     post-estimation             :  00:00:1.52 
Iterations                       :  157  

Unconstrained optimisation.

Estimates:
                       Estimate        s.e.   t.rat.(0)  p(1-sided)    t.rat(1)  p(1-sided)    Rob.s.e. Rob.t.rat.(0)  p(1-sided) Rob.t.rat.(1)  p(1-sided)
asc_car_simple          0.00000          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
asc_car_complex        -0.52828          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
asc_walk_simple       763.28248          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
asc_walk_complex      760.48058          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
asc_transit_simple    -50.67288          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
asc_transit_complex   -64.44870          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
b_tt_car                0.01214          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
b_tt_walk             -11.44721          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
b_tt_transit           -2.87021          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
b_cost                 20.00123          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
lambda_simple         208.10415          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
lambda_complex        210.33763          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA

Nesting structure for NL model component :
Nest: root (1)
|-Nest: simple (208.1042)
|  |-Alternative: car_simple
|  |-Alternative: walk_simple
|  '-Alternative: transit_simple
'-Nest: complex (210.3376)
   |-Alternative: car_complex
   |-Alternative: walk_complex
   '-Alternative: transit_complex

WARNING: The nesting parameter for nest "simple" should be between 0 and 1 (the nesting parameter for nest "root"), yet its value is 208.1042.

WARNING: The nesting parameter for nest "complex" should be between 0 and 1 (the nesting parameter for nest "root"), yet its value is 210.3376.

with lambda_simple = 1, the results look much more reasonable (except the positive cost coefficient), but the interpretation the lambda_simple fixed to 1.0 and the estimated lambda_complex remains a mystery to me:

Code: Select all

Model name                       : TNL_1.1_summer
Model description                : Tour-based NL model with TT + COST generic. Nesting: simple vs. complex
Model run at                     : 2022-01-05 12:14:20
Estimation method                : bfgs
Model diagnosis                  : successful convergence 
Number of individuals            : 289
Number of rows in database       : 511
Number of modelled outcomes      : 511

Number of cores used             :  1 
Model without mixing

LL(start)                        : -633.4515
LL(0)                            : -679.7981
LL(C)                            : -508.264
LL(final)                        : -428.6949
Rho-square (0)                   :  0.3694 
Adj.Rho-square (0)               :  0.3547 
Rho-square (C)                   :  0.1566 
Adj.Rho-square (C)               :  0.1369 
AIC                              :  877.39 
BIC                              :  919.75 

Estimated parameters             :  10
Time taken (hh:mm:ss)            :  00:00:3.89 
     pre-estimation              :  00:00:0.13 
     estimation                  :  00:00:2.5 
     post-estimation             :  00:00:1.26 
Iterations                       :  40  
Min abs eigenvalue of Hessian    :  1.354019 

Unconstrained optimisation.

Estimates:
                       Estimate        s.e.   t.rat.(0)  p(1-sided)    t.rat(1)  p(1-sided)    Rob.s.e. Rob.t.rat.(0)  p(1-sided) Rob.t.rat.(1)  p(1-sided)
asc_car_simple         0.000000          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
asc_car_complex       -1.123765     0.14984     -7.4996   3.197e-14     -14.173     0.00000     0.20371       -5.5166   1.728e-08      -10.4256     0.00000
asc_walk_simple        3.278206     0.37951      8.6381     0.00000       6.003   9.680e-10     0.46147        7.1039   6.064e-13        4.9369   3.969e-07
asc_walk_complex       1.770551     0.37789      4.6854   1.397e-06       2.039     0.02072     0.39147        4.5229   3.050e-06        1.9684     0.02451
asc_transit_simple    -1.424081     0.36593     -3.8917   4.977e-05      -6.624   1.743e-11     0.38414       -3.7071  1.0480e-04       -6.3103   1.392e-10
asc_transit_complex   -1.740878     0.76023     -2.2899     0.01101      -3.605  1.5589e-04     1.45577       -1.1958     0.11588       -1.8828     0.02987
b_tt_car              -0.013776     0.02971     -0.4637     0.32145     -34.119     0.00000     0.06378       -0.2160     0.41450      -15.8942     0.00000
b_tt_walk             -0.047172     0.01057     -4.4648   4.007e-06     -99.115     0.00000     0.02079       -2.2686     0.01165      -50.3613     0.00000
b_tt_transit          -0.006009     0.01269     -0.4735     0.31794     -79.263     0.00000     0.02686       -0.2237     0.41149      -37.4519     0.00000
b_cost                 0.023027     0.03520      0.6542     0.25650     -27.755     0.00000     0.03894        0.5913     0.27715      -25.0892     0.00000
lambda_simple          1.000000          NA          NA          NA          NA          NA          NA            NA          NA            NA          NA
lambda_complex         0.477712     0.34821      1.3719     0.08505      -1.500     0.06682     0.71996        0.6635     0.25350       -0.7254     0.23409

Nesting structure for NL model component :
Nest: root (1)
|-Nest: simple (1)
|  |-Alternative: car_simple
|  |-Alternative: walk_simple
|  '-Alternative: transit_simple
'-Nest: complex (0.4777)
   |-Alternative: car_complex
   |-Alternative: walk_complex
   '-Alternative: transit_complex

Regarding your question:

My assumptions is that alternatives on simple tours may share some unobserved characteristics that are different to alternatives on complex tours, which could be reflected in the lambda parameter significantly different from 1.

I have no nest-specific variables. Travel time is of course mode-specific. Cost is generic. Utilities are as follows:

Code: Select all

    V <- list()
        V[['car_simple']]           <- asc_car_simple + 
                                       b_tt_car                * tour_tt_driving +
                                       b_cost                  * tour_cost_driving
        V[['car_complex']]          <- asc_car_complex + 
                                       b_tt_car                * tour_tt_driving +
                                       b_cost                  * tour_cost_driving
        
        V[['walk_simple']]          <- asc_walk_simple +
                                       b_tt_walk               * tour_tt_walk
        V[['walk_complex']]         <- asc_walk_complex +
                                       b_tt_walk               * tour_tt_walk
        
        V[['transit_simple']]       <- asc_transit_simple +
                                       b_tt_transit            * tour_tt_transit +
                                       b_cost                  * tour_cost_transit
        V[['transit_complex']]      <- asc_transit_complex +
                                       b_tt_transit            * tour_tt_transit +
                                       b_cost                  * tour_cost_transit

The availabilities are controlled by the same variables for both simple and complex. I have of course cases when only one alternative is available (e.g. captive drivers), but it doesn't affect the estimation I guess, does it?

Code: Select all

        avail        = list(car_simple = tour_avail_car, walk_simple = tour_avail_walk, transit_simple = tour_avail_transit,
                            car_complex = tour_avail_car, walk_complex = tour_avail_walk, transit_complex = tour_avail_transit)

What is going wrong here?

Bartosz

Post by **stephanehess** » 06 Jan 2022, 07:02

Bartosz

are you able to share the data with me?

Best wishes

Stephane

bartosz · Post by **bartosz** » 07 Jan 2022, 08:39

Of course, you should have it on your mailbox already.
Thanks again for your time.

Bartosz

Post by **stephanehess** » 07 Jan 2022, 18:07

Bartosz

we had a look at this. In your model, the attributes do not differ between the simple and complex version of each alternative. So the model is able to explain the choice between these only through the constant, and as the constants are nest-specific, you cannot then estimate the structural parameter for a nest. Is this really what you in mind for your model?

Stephane

bartosz · Post by **bartosz** » 11 Jan 2022, 09:47

Stephane

Thank you very much for having a look at the data and pointing out the problems with my model.

You are correct, the attributes do not differ between simple and complex tours because I do not suppose that people perceive time and cost in a different way depending on how complex their daily schedule is (but I will give it a try).

However, I suspect that there are some common characteristics of driving, walking, and transit on a simple tour that are different from common characteristics of driving, walking, and transit on a complex tour. And that it is not about time and cost - that's why I didn't make them nest-specific. This is one reason for the NL specification with this particular nesting structure. Another reason is that I wanted to model two choices actually: (1) choice of tour complexity, (2) and choice of travel mode.

So, if I want to give the NL model some sense and make it estimable, I have the following options:

make time and cost coefficients nest-specific
make ASCs mode-specific (but not nest-specific)
introduce some nest-specific or mode&nest-specific variables that would affect the decision between simple and complex (e.g. age or company on a tour)

Am I right regarding the above?

Bartosz

Post by **stephanehess** » 14 Jan 2022, 16:57

Bartosz

I'm still not clear what you are trying to do here exactly, or why you want a nested logit model for it. Nested logit is not a model of sequential choice behaviour. So it would not model the choice of tour type followed by mode, as the dependent variable in your model is the mode

But making the coefficients nest specific will not help. The problem is that the attributes are the same

Stephane

bartosz · Post by **bartosz** » 18 Jan 2022, 17:15

Stephane

thanks again for looking at this.

stephanehess wrote: ↑14 Jan 2022, 16:57 I'm still not clear what you are trying to do here exactly, or why you want a nested logit model for it. Nested logit is not a model of sequential choice behaviour. So it would not model the choice of tour type followed by mode, as the dependent variable in your model is the mode

Actually, the dependent variable is a combination of tour complexity and transport mode: simple car, simple transit, complex car, ...

Alternatively, instead of using the combined DVs as above, one could use a bivariate model with two separate dependent variables: (1) mode choice and (2) tour complexity, as Ye & Pendyala (2007) did. They write:

The relationship between these two aspects of travel behavior is represented in this paper by considering three different causal structures: one structure in which the trip chaining pattern is determined first and influences mode choice, another structure in which mode choice is determined first and influences the complexity of the trip chaining pattern, and a third structure in which neither is predetermined but both are determined simultaneously. The first two structures are estimated within a recursive bivariate probit modeling framework that accommodates error covariance. The simultaneous logit model is estimated for the third structure that allows a bidirectional simultaneous causality.

Is it possible to specify a bivariate model in Apollo?

----------------------------------------

stephanehess wrote: ↑14 Jan 2022, 16:57 But making the coefficients nest specific will not help. The problem is that the attributes are the same

Ok, I think I finally get it. I was trying to follow what Hensher & Reyes (2000) did in their paper, where they applied MNL, NL and MMNL to Sydney HTS data to study trip chain choices. They combined different trip chaining patterns (H-W-H, H-W-NW-H, etc.) and two modes (car, PT) into 11 mode-chain combinations. So did I, by creating 6 alternatives from 2 levels of complexity and 3 modes.

What I did differently, however, is that I started with a "base" model with only travel time and cost (with a plan to expand it), and no other variables, and got stuck at the confusing outcomes that I obtained. As you noticed in a previous post, I tried to model a choice between e.g. transit on a simple tour and transit on a complex tour without actually having any variable affecting this choice, because I only had time and cost, which are identical in this case. Whereas Hensher & Reyes operated with characteristics of the individuals (age, income, ...) and alternative-specific coefficients, which made it possible to capture e.g. the effect of age on the choice of car for a simple tour and for a complex tour separately.

I need to modify the utility functions (= add sociodemographic variables), so that the utility of simple and complex can be different. I will test it with MNL and then NL and see whether it performs better.

Post by **stephanehess** » 24 Jan 2022, 13:21

Hi

if you can write probabilities for such a model, then you can implement yourself in Apollo

Stephane

ApolloChoiceModelling forum

Nested Logit - fixed lambda (NNNL vs. UMNL)

Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)

Re: Nested Logit - fixed lambda (NNNL vs. UMNL)