RMetrics fBasics market data retrieval and timeSeries functionality still being maintained at all?

sessionInfo()

IBM = yahooSeries("IBM")

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