[Eventstudies-discussion] Class for event time

[Chirag Anand]

On 11 August 2014 22:19, Vimal Balasubramaniam <vimsaa at gmail.com> wrote:
> 1. What confusion does this create? Is it confusion because of the column
> name of the events data frame? If so, we could generalise it and let people
> choose whatever they want it to be. Let's just name it 'x' and 'y' where 'x'
> refers to a timestamp or the dimension along which an event analysis must
> happen and 'y' being the subject of such analysis. If more users have a
> concern with this, am happy to go along and take suggestions in modifying
> this.

A couple of users do have issues with the "when" and "unit" way of
creating the data frame, they find it confusing. If we do follow "x"
and "y" way, then we'll have to add another argument to the main
eventstudy() function and to phys2eventtime(). eventstudy() already
has a quite a lot of arguments.

Keeping event.list in zoo makes it consistent with the data user is
supplying, and is in my opinion more intuitive.

> If the trouble is to ensure that class(event.list$when) == class(index(d))
> (the data set), then we could just throw that as a warning? I don't think it
> making it a zoo object helps (if users choose to keep strange class for the
> underlying index(), then there's anyway little we can do) here. We just need
> bells and whistles when such things happen?

Yes, checking for argument time class makes sense. Throwing a
warning() in case of no exact match of event time too. Yes, zoo won't
help much in this case.

>> For this, I have thought of two solutions:
>>
>> 1. We keep the current API and ask the users to give us the "when"
>> column in the time-based class which defines the index of the main
>> object. phy2eventtime converts this to a zoo index directly, thus
>> maintaining the original time-based class.
>
>
> Sure. Adding a line of code like:
>
> if(class(d)!= class(event.list$when)) stop("Date/Time class for 'd' and
> 'event.list$when' do not match.")
>
> will be easier?

Yes.

>> 2. We ask the user to give event.list as a zoo object directly.
>>
>> The second solution, in my opinion will also eliminate the problem of
>> defining "unit" and "when" in the event.list object.
>
>
> Users will have to provide that, no? In some form or the other. While I
> agree that users may find it initially troublesome to work this through, I
> think bells and whistles as to why they may be going to wrong is better than
> making the code more complex in terms of the API.

Though I agree but I don't think making event.list a zoo object will
create make API more complex. On the other hand, the way I see it, it
will help to have event.list object the same class as firm.returns,
since one can directly index firm.returns to pick out event times.

-- 
Chirag Anand
http://atvariance.in/chiraganand