[Eventstudies-discussion] Class for event time

[Vimal Balasubramaniam]

Sure, I think this sounds good.
On 16 Aug 2014 12:40, "Chirag Anand" <anand.chirag at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/eventstudies-discussion/attachments/20140816/dd12c393/attachment.html>