<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 2 August 2014 15:07, Chirag Anand <span dir="ltr"><<a href="mailto:anand.chirag@gmail.com" target="_blank">anand.chirag@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":vy" class="a3s" style="overflow:hidden">Hello,<br>
<br>
The current development version (1.2) deals with event time by taking<br>
in a data.frame of event (say) dates in the column "when" and the unit<br>
of observation in "unit". One, this creates a confusion for the user,<br>
and secondly, it makes harder for the phys2eventtime function to match<br>
the dates specially when the exact event time is missing from the<br>
observations.<br>
<br></div></blockquote><div><br></div><div>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. </div>

<div><br></div><div>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. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":vy" class="a3s" style="overflow:hidden">
In my opinion, having event time (event.list object) as a 'zoo' object<br>
solves the matching problem. The index() of both the zoo objects, the<br>
actual observations and event list can be used to match using<br>
findInterval(). Since the class of the event time will be defined,<br>
there won't be an issue dealing with say intraday or monthly data.<br>
<br></div></blockquote><div><br></div><div>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? </div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":vy" class="a3s" style="overflow:hidden">
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></div></blockquote><div><br></div><div>Sure. Adding a line of code like: </div><div><br></div><div>if(class(d)!= class(event.list$when)) stop("Date/Time class for 'd' and 'event.list$when' do not match.")</div>

<div><br></div><div>will be easier? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":vy" class="a3s" style="overflow:hidden">
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></div></blockquote></div><br>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. </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Just my two cents. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Vimal <br><br clear="all"><div><br></div>-- <br><br>Vimal Balasubramaniam<br>

<br>+44 755 750 4880<br>+91 981 829 8975
</div></div>