[Eventstudies-discussion] Class for event time

[Vimal Balasubramaniam]

On 2 August 2014 15:07, Chirag Anand <anand.chirag at gmail.com> wrote:

> Hello,
>
> The current development version (1.2) deals with event time by taking
> in a data.frame of event (say) dates in the column "when" and the unit
> of observation in "unit". One, this creates a confusion for the user,
> and secondly, it makes harder for the phys2eventtime function to match
> the dates specially when the exact event time is missing from the
> observations.
>
>
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.

2. When exact event time is missing, the function (as far as I can tell)
takes the nearest date to match. Perhaps of relevance would be a warning to
the user at that point when the function takes the nearest match? This has
been documented appropriately.


> In my opinion, having event time (event.list object) as a 'zoo' object
> solves the matching problem. The index() of both the zoo objects, the
> actual observations and event list can be used to match using
> findInterval(). Since the class of the event time will be defined,
> there won't be an issue dealing with say intraday or monthly data.
>
>
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?



> 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?


> 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.

Just my two cents.

Vimal


-- 

Vimal Balasubramaniam

+44 755 750 4880
+91 981 829 8975
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/eventstudies-discussion/attachments/20140811/549e8c7c/attachment.html>