Aggregate logit

[yoshida-gisc]

Although the mclogit function can calculate logit models for not only count (the Molel 1 below) but also share/ratio (the Model 2 below), the detail for the model 2 is currently not described in the manual. So, I would like to know whether the model 2 is correspond to the aggregate logit model or not.

library(mclogit)
data(Transport)
### Model 1: for count
mclogit(cbind(resp, suburb)~distance+cost,data=Transport) 
### Model 2: for share/ratio 
mclogit(cbind(prop.true, suburb)~distance+cost,data=Transport) 

Best wishes and thank you so much for the very flexible package!

[melff]

I think if total is the total number of idividuals from which the proportion is computed then the aggregate model could be fitted as:

mclogit(cbind(total*prop.true, suburb)~distance+cost,data=Transport) 

or

mclogit(cbind(prop.true, suburb)~distance+cost,data=Transport,
        weights=total) 

[yoshida-gisc]

Thank you very much for your prompt reply! I gotcha.

Just for making sure. In the data(Transport) case, total number of resp in suburb 1, 2, and 3 is 212, 212, 219, respectively. But, if we can not know the total number (that is, if we know only ratio), the code mclogit(cbind(prop.true, suburb)~distance+cost,data=Transport) will not be good and not correspond to the aggregate model, right?

So, mclogit(cbind(prop.true, suburb)~distance+cost,data=Transport) will be misleading as aggregate logit model.

[melff]

If you have only the proportions, then the results will be the same as in the case where the number of responses is the same in all suburbs. However, the inference will be much more conservative. This is not a problem of this particular implementation, but of any logit model, because the (inverse) number of the responses is used to compute the standard errors.

[yoshida-gisc]

@melff Yes, I see this is not implementation problem. Thank you so much for your kind help and providing useful package!