<p dir="ltr">Sure, I think this sounds good. </p>
<div class="gmail_quote">On 16 Aug 2014 12:40, "Chirag Anand" <<a href="mailto:anand.chirag@gmail.com">anand.chirag@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11 August 2014 22:19, Vimal Balasubramaniam <<a href="mailto:vimsaa@gmail.com">vimsaa@gmail.com</a>> wrote:<br>
> 1. What confusion does this create? Is it confusion because of the column<br>
> name of the events data frame? If so, we could generalise it and let people<br>
> choose whatever they want it to be. Let's just name it 'x' and 'y' where 'x'<br>
> refers to a timestamp or the dimension along which an event analysis must<br>
> happen and 'y' being the subject of such analysis. If more users have a<br>
> concern with this, am happy to go along and take suggestions in modifying<br>
> this.<br>
<br>
A couple of users do have issues with the "when" and "unit" way of<br>
creating the data frame, they find it confusing. If we do follow "x"<br>
and "y" way, then we'll have to add another argument to the main<br>
eventstudy() function and to phys2eventtime(). eventstudy() already<br>
has a quite a lot of arguments.<br>
<br>
Keeping event.list in zoo makes it consistent with the data user is<br>
supplying, and is in my opinion more intuitive.<br>
<br>
> If the trouble is to ensure that class(event.list$when) == class(index(d))<br>
> (the data set), then we could just throw that as a warning? I don't think it<br>
> making it a zoo object helps (if users choose to keep strange class for the<br>
> underlying index(), then there's anyway little we can do) here. We just need<br>
> bells and whistles when such things happen?<br>
<br>
Yes, checking for argument time class makes sense. Throwing a<br>
warning() in case of no exact match of event time too. Yes, zoo won't<br>
help much in this case.<br>
<br>
>> For this, I have thought of two solutions:<br>
>><br>
>> 1. We keep the current API and ask the users to give us the "when"<br>
>> column in the time-based class which defines the index of the main<br>
>> object. phy2eventtime converts this to a zoo index directly, thus<br>
>> maintaining the original time-based class.<br>
><br>
><br>
> Sure. Adding a line of code like:<br>
><br>
> if(class(d)!= class(event.list$when)) stop("Date/Time class for 'd' and<br>
> 'event.list$when' do not match.")<br>
><br>
> will be easier?<br>
<br>
Yes.<br>
<br>
>> 2. We ask the user to give event.list as a zoo object directly.<br>
>><br>
>> The second solution, in my opinion will also eliminate the problem of<br>
>> defining "unit" and "when" in the event.list object.<br>
><br>
><br>
> Users will have to provide that, no? In some form or the other. While I<br>
> agree that users may find it initially troublesome to work this through, I<br>
> think bells and whistles as to why they may be going to wrong is better than<br>
> making the code more complex in terms of the API.<br>
<br>
Though I agree but I don't think making event.list a zoo object will<br>
create make API more complex. On the other hand, the way I see it, it<br>
will help to have event.list object the same class as firm.returns,<br>
since one can directly index firm.returns to pick out event times.<br>
<br>
--<br>
Chirag Anand<br>
<a href="http://atvariance.in/chiraganand" target="_blank">http://atvariance.in/chiraganand</a><br>
</blockquote></div>