[R-SIG-Finance] RMetrics fBasics market data retrieval and timeSeries functionality still being maintained at all?

[David-Michael Lincke]

Martin,

I did run update.packages() after I first encountered problems, which
suggested that no newer version was available. The source code of
yahooImport() clearly scans for dates with format along the lines of
2007-Aug-01 while Yahoo actually delivers 2007-08-01. Here is the output
from sessionInfo():

> sessionInfo()
R version 2.4.0 (2006-10-03) 
i386-pc-mingw32 

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets" 
[7] "base"     

other attached packages:
      fBasics     fCalendar       fEcofin          MASS 
"240.10068.1"   "240.10068"   "240.10067"      "7.2-34"

David

-----Original Message-----
From: Martin Maechler [mailto:maechler at stat.math.ethz.ch] 
Sent: Tuesday, August 14, 2007 12:03 PM
To: David-Michael Lincke
Cc: 'Diethelm Wuertz'; r-sig-finance at stat.math.ethz.ch
Subject: Re: [R-SIG-Finance] RMetrics fBasics market data retrieval and
timeSeries functionality still being maintained at all?


>>>>> "DL" == David-Michael Lincke <dlincke at lincke.net>
>>>>>     on Sun, 12 Aug 2007 21:11:39 -0400 writes:

    DL> Diethelm,
    DL> Thank you for your response. Asyt.ts in my example is a timeSeries
object
    DL> constructed using yahooSeries(). Trying out the example you provided
I get:

    >> IBM = yahooSeries("IBM")
    DL> trying URL
    DL>
'http://chart.yahoo.com/table.csv?s=IBM&a=7&b=12&c=2006&d=7&e=12&f=2007&g=d&
    DL> x=.csv'
    DL> Content type 'text/csv' length unknown
    DL> opened URL
    DL> downloaded 12Kb

    DL> Read 250 items
    DL> Error in matrix(unlist(x2), byrow = TRUE, nrow = length(x2)) : 
    DL> matrix: invalid 'ncol' value (< 0)
    DL> Error in .yahooSeries(symbols[1], from = from, to = to, nDaysBack =
    DL> nDaysBack,  : 
    DL> cannot get a slot ("data") from an object of type "character"

David,
I can confirm Diethelm's statement that  yahooSeries()
works without problems 

__IFF__ you use current versions of R and fBasics.

Can you give your
    sessionInfo() ## {after having loaded  fBasics} ?

I'm pretty sure your version of fBasics is not current enough.

    DL> After applying the patch to yahooImport() that I posted in my
initial
    DL> message the import works:

    >> IBM = yahooSeries("IBM")
    DL> trying URL
    DL>
'http://chart.yahoo.com/table.csv?s=IBM&a=7&b=12&c=2006&d=7&e=12&f=2007&g=d&
    DL> x=.csv'
    DL> Content type 'text/csv' length unknown
    DL> opened URL
    DL> downloaded 12Kb

    DL> Read 250 items
    DL> Read 7 items

    >> colnames(IBM)
    DL> [1] "IBM.Open"   "IBM.High"   "IBM.Low"    "IBM.Close"  "IBM.Volume"

    DL> Given that plot() has been overloaded to deal with timeSeries
objects I
    DL> would have expected it to have some default functionality when
passed a
    DL> timeSeries object short of unceremoniously failing in a lower level
function
    DL> call. I did not realize it only works on single columns/data series.

    DL> As for ohlcDailyPlot(), I checked the source code later on and
realized that
    DL> it expects column names that are different from how the market data
    DL> retrieval functions construct their timeSeries objects. This is
easily
    DL> adjusted for. However, it's not exactly a smooth solution from a
design
    DL> point of view. Also, the documentation does not mention the need for
an
    DL> explicit prior call to par(mfrow = c(2, 1)) for it to result in a
proper
    DL> plot. But I guess maybe that's obvious to a more seasoned R user
than me.

    DL> Anyway, thank you for pointing me in the right direction. The code
in
    DL> yahooImport(), however, really is broken as you can clearly verify
by taking
    DL> a look at the date format delivered by Yahoo which does not have
spelled out
    DL> three letter month names as expected by the source code.


I partly agree with you, that the documentation of several of
the Rmetrics functions is clearly "sub-optimal".
There's currently an ongoing effort to make Rmetrics being
loaded on more shoulders than just Diethelm's and I'd hope that
consequently many things will improve on the documentation front
...

Best regards,
Martin

    DL> David