set estimation.period

[Thicool]

Is there any way to manually configure the estimation period for the expected returns regression? In a time series with multiple events, one might want to exclude events from the estimation task.

Thanks in advance

[Christopher-Gross90]

/push

I have the same question and kindly ask how to adapt the estimation period to [-250,-6], b/c I don't want to use the default setting since it includes the first day of the event window (not applicable for short event windows like [-1,1] from my perspective).

I just found this code/commentary in the function eventstudy, but the estimation period is not defined here.

'## compute estimation and event period '## event period starts from event time + 1 'event.period <- as.character((-event.window+1):event.window)

Thank you so much in advance!

[danielkosz]

/push

I would have the same question: How can one manually specify the estimation period for the model parameters (e.g. to [-120, -10]) to exclude the impact of pre-announcement effects?

Does setting the estimation.period in model.args to the desired range do the trick? If I use the code below, I do get reasonable results but am wondering if that is indeed the correct specification to get the job done:

eventstudy(returns.data.zoo , filing.dates , event.window = 1 , type = "marketModel" , to.remap = TRUE , remap = "cumsum" , is.levels = FALSE , inference = TRUE , inference.strategy = "bootstrap" , model.args = list(market.returns = vwret.zoo , estimation.period = -120:-10))

Thank you very much for your help!

[Christopher-Gross90]

Hello again, first and foremost cool that I am not the only one struggling with this problem ;)

Regarding your suggestion: I'm pretty sure the estimation.period argument is simply ignored by the eventstudy function since it leads to exactly identical CARs (10-decimal-digit) like computing the standard procedure (at least with my data).

Nevertheless I digged deeper and it seems like I found a solution:

By editing the eventstudy function via --> trace("eventstudy", edit = TRUE) it is possible to overwrite the estimation period in the source code.

Disclaimer: I'm not a genuine programmer and I bet there is a better solution for this problem

Cf. the following code which is part of the function eventstudy:

 if (type == "marketModel") {
         if (length(dim(model.args$market.returns)) == 2) {
             colnames(model.args$market.returns) <- "market.returns"
         }
         returns.zoo <- prepare.returns(event.list = event.list, 
             event.window = event.window, list(firm.returns = firm.returns, 
                 market.returns = model.args$market.returns))

                                                                  […]

                estimation.period <- attributes(firm)[["estimation.period"]]
                estimation.period <- -120:-10 #overwrite_estimation_period
                model <- marketModel(firm$z.e[estimation.period, 

Looking forward to your feedback and further suggestions.

Christopher

[chiraganand]

Estimation period is computed inside prepare.returns (not exported) function. The exact line of code where this is done:

attr(firm.returns.eventtime, which = "estimation.period") <-
        as.character(index(firm.returns.eventtime$z.e)[1]:(-event.window))

Since this is a required feature I think we can introduce a new argument for estimation period in the main eventstudy() function with current default of range from first observation till the event start. This argument can be passed on to prepare.returns() for correct computation of estimation period.

I will have to look for other regressions arising out of this, if any, so might take some time before I push the code.

[ashimkapoor]

Have implemented here : setting-estimation-period

Feedback is welcome.

[chiraganand]

@ashimkapoor I realised that, since events are processed one at a time based on the number of entries inside event.list, hence, we cannot introduce estimation.period as a standalone global argument to eventstudy(). Estimation period is currently calculated separately for each event because the period depends on the number of data points available in firm.returns for each name in event.list. If we introduce a global estimation.period then it may not apply for all events.

There are two possibilities I see for solving this:

1. Allow event.list to have one more column with a range of estimation period which applies to specific events. For example:

event.list <- data.frame(
    name = c("FirmA", "FirmB"),
    when = as.Date(c("2019-10-02", "2019-03-23")),
    estimation.period = c("-70:-8", "-250:-10")
)

This approach will require users to fill in estimation periods for all events which may not be desirable and cumbersome. One can always use defaults if values are NULL in estimation.period column.

2. Introduce a separate estimation.period to eventstudy() function, where, a user can specify the N^th event and estimation period they want to use. Given an event.list like:

   name       when
   1 FirmA 2019-10-02
   2 FirmB 2019-03-23
   3 FirmC 2018-08-17
   4 FirmD 2017-04-02

The estimation.period argument could be:

estimation.period <- data.frame(
  event = c(2, 4),  ## correspond to `FirmB` and `FirmD` events
  period = c("-70:-8", "-250:-10")
)
> estimation.period
   event   period
 1     2   -70:-8
 2     4 -250:-10

If there are more approaches then we can discuss them.

@ashimkapoor I looked at changes in the following commits in https://github.com/ashimkapoor/eventstudies/commits/setting-estimation-period:

• 6e27a17f4e47c394f2b3372cec685678fe11f028
• 839c0c4bc8fea87817c0290d4c612db5a11f869f
• dd90e61efa2b8b69d3427075590e677e7d4aeede
• a693f4a170c75905df0dd5c8a0020f4a65e3a6ca

PS: It is better to do a pull request if you want to submit a patch which can then be reviewed in one go.

[ashimkapoor]

@chiraganand I think there are 2 approaches to be implemented :

1. Different estimation periods for each firm (as you have suggested).
2. (As a particular case of the above) ONE estimation period for MULTIPLE events in ONE time series. (as suggested by Thicool)

Can everyone agree on this before we implement the above ?

[Christopher-Gross90]

First off all, thank you guys for your comittment.

Regarding the problematic setup of a global estimation.period:

• Would it be applicable to implement a event specific error handler/warning in case a given "global estimation.period" is ignored due to lack of data points?

• Why am I asking this? From my perspective this would drastically improve the "user experience" b/c one must only set an event specific estimation.period if A. he decides it apriori or B. the global estimation.period does not fit the underlying time series.

One question in advance: the es() object contains the different event and firm specific CARs in one of the attributes. In processing the data through es() the "name" argument in event.list is erased (as far as I know) and only an index remains. Is it possible - for further data processing - to rematch the firm indicator with the corresponding CAR values? I have currently implemented a (nonperfect) workaround which imputes that the ranking of event.list is exactly the same as the ranking of the CAR index.

Greetings & as always thank you in advance, Christopher

[chiraganand]

First off all, thank you guys for your comittment.

Regarding the problematic setup of a global estmation.period: Would it be applicable to implement a event specific error handler/warning in case a given "global estimation.period" is ignored due to lack of data points?

One can always throw a warning a period doesn't fit in.

Why am I asking this? From my perspective this would drastically improve the "user experience" b/c one must only set an event specific estimation.period if A. he decides it apriori or B. the global estimation.period does not fit the underlying time series.

I think I somewhat follow what you are suggesting but I am a bit confused regarding the two scenarios. I agree that estimation.period should not be global but we should also not provide two ways of providing the period, that is, global and specific. There should only be one estimation.period input.

One question in advance: the es() object contains the different event and firm specific CARs in one of the attributes. In processing the data through es() the "name" argument in event.list is erased (as far as I know) and only an index remains. Is it possible - for further data processing - to rematch the firm indicator with the corresponding CAR values? I have currently implemented a workaround which imputes that the ranking of event.list is exactly the same as the ranking of the CAR index.

The reason why name is not used in output is because there could be multiple events with same name which would become columns of the output object, hence, confusing while subsetting and other operations. So the output is organised by the N^th event from event.list.