Hi Users,
             I am working on F&O order-book data, and I noticed index of
subset of data is missing? Usually when you type the variable name it shows
you row numbers like [1,], [2,] etc., but here row number is missing. When I
ask for dim(data) command , it shows "NULL" ? Please see below

> rel_data
       symbols insuments_type    expire date       quantity          price
  time_stamp             BS     order_type
  "JPASSOCIAT"       "FUTSTK"     "20080424"          "750"       "240.90"
  "13:55:30"            "S"           "RL"
> dim(rel_data)
NULL
> rel_data[1,]
Error in rel_data[1, ] : incorrect number of dimensions
>



On Tue, Sep 1, 2009 at 11:02 PM, Jeff Ryan <jeff.a.ryan@gmail.com> wrote:

> Jatin,
>
> quantmod charts need non-unique values at present.  I suspect that
> will always be the case, as the x-index relies on time.
>
> xts can handle merging with non-unique timestamps, but keep in mind
> that many operations would be quite ill-defined.  Merging will work,
> but Ops methods (+-/* etc) will make little sense if you aren't
> cognisant of what is actually being performed. diff() and lag() will
> also be problematic.
>
> Aside from that, the myriad of documentation available on zoo (great),
> xts (less great, but good), and using the above and R in finance
> (check the list archives... learn the list archives) is quite
> impressive.
>
> Obviously the caliber of the reply on this list is awe inspiring as
> well, but asking questions should really be a last resort, and only if
> they haven't been asked before.
>
> Jeff
>
>
> On Tue, Sep 1, 2009 at 12:22 PM, Gabor
> Grothendieck<ggrothendieck@gmail.com> wrote:
> > Note that for any calculation that involves merge.zoo (which
> > is most calculations since even z1 + z2 can do a
> > merge underneath) one does require unique times in zoo.
> > read.zoo can read in times that are not unique but ultimately
> > you will want to make them unique for most operations.
> >
> > The aggregate= argument of read.zoo provides a way to
> > collapse duplicates and there are additional facilities in the
> > devel version of zoo.
> >
> > As indicated in my prior post in this thread zoo FAQ #1
> > has further discussion.
> >
> > On Tue, Sep 1, 2009 at 1:13 PM, Brian G. Peterson<brian@braverock.com>
> wrote:
> >> jatin patni wrote:
> >>>
> >>> I'm trying to create a zoo object from a tick data file(sample below)
> >>> which
> >>> contains timestamps only.
> >>> Filename: "20080202.trd"
> >>> 1|BHARTIARTL|EQ|18:15:05|600|1
> >>> 2|BHARTIARTL|EQ|18:15:05|600|99
> >>> 3|GLENMARK|EQ|18:15:05|238.1|5
> >>> 4|HINDALCO|EQ|18:15:05|43.75|100
> >>> 5|BHARTIARTL|EQ|18:15:05|600|1
> >>> 6|BHEL|EQ|18:15:05|1100|11
> >>> 7|HINDALCO|EQ|18:15:06|43.2|1
> >>> 8|CHAMBLFERT|EQ|18:15:06|46|10
> >>> 9|CHAMBLFERT|EQ|18:15:06|46|90
> >>> 10|BAJAUTOFIN|EQ|18:15:06|80|100
> >>>
> >>> As you can see that timestamps are not unique even at microsecond
> levels.
> >>> Inorder to create a zoo/xts object to be used with quantmod later, How
> do
> >>> I:-
> >>> 1)Do I have to merge two rows with the same timestamp, symbols, price
> but
> >>> different volumes.(Do I need to do this or is there some other way
> >>> possible)
> >>> 2)Append date to the timestamp while creating the zoo/xts object
> >>>
> >>> I'm trying to explore the 'format' argument, and POSIX and chron but
> >>> without
> >>> much success.
> >>>
> >>
> >> Your target should be POSIXct, as that is what xts uses internally,
> given
> >> that your stated goal is to use xts and quantmod.
> >>
> >> ?as.POSIXct
> >> ?format.POSIXct
> >>
> >> These look like one second bars, not microsecond bars.  To see
> microseconds,
> >> if you have them:
> >>
> >> options(digits.secs=6)
> >>
> >> zoo doesn't require unique timestamps, just ordered ones.  In this case,
> >> your trades are ordered in the files.  You might need to append an order
> in
> >> the microseconds if you really only have second bars.  It's also not
> >> necessary to have unique timestamps, but you'll be happier if you do.
> >>
> >> Regards,
> >>
> >>  - Brian
> >>
> >>
> >> --
> >> Brian G. Peterson
> >> http://braverock.com/brian/
> >> Ph: 773-459-4973
> >> IM: bgpbraverock
> >>
> >> _______________________________________________
> >> R-SIG-Finance@stat.math.ethz.ch mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> >> -- Subscriber-posting only.
> >> -- If you want to post, subscribe first.
> >>
> >
> > _______________________________________________
> > R-SIG-Finance@stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> > -- Subscriber-posting only.
> > -- If you want to post, subscribe first.
> >
>
>
>
> --
> Jeffrey Ryan
> jeffrey.ryan@insightalgo.com
>
> ia: insight algorithmics
> www.insightalgo.com
>
> _______________________________________________
> R-SIG-Finance@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only.
> -- If you want to post, subscribe first.
>

	[[alternative HTML version deleted]]

