3

I have some experience in R but so far never used my own environment. Over the last months I had to use my own environment from time to time and I have some questions about it.

  • The main reason for using an environment as "data-container" is because it is much faster then others, right? For example, using the quantmod why do we load OHLC objects into an environment by using getSymbols?

Having such a new environment coming from getSymbols, i.e. 

tick = c( "VNO" , "VMC" , "WMT" , "WAG") 
data.env <- new.env()    start<-as.Date("2013-01-01")   
getSymbols(tick,env=data.env,src="yahoo",from=start)

How can we efficiently access members in data.env, e.g. if we want to check if all members in data.env are OHLC objects can we do something like: is.OHLC(data[[all elements]])?

Moreover, for the above examples of data, how can I calculate the Value at Risk for such a portfolio. My idea was to us the function VaR from the PerformanceAnalytics library. The help page of VaR says as argument: "an xts, vector, matrix, data frame, timeSeries or zoo object of asset returns". For this purpose I wanted to use dailyReturn to get the returns, which then can be used for the function VaR. However dailyReturn needs an OHLC object as argument. Hence I can calculate VaR as soon as I know how to turn the elements in data.env to a OHLC matrix

math
  • 1,868
  • 4
  • 26
  • 60

2 Answers2

2

The main reason for using an environment as "data-container" is because it is much faster then others, right?

No, I think the main reason is to keep things clean and avoid overwriting objects in your global environment. (In addition, to have all "new" objects as a "bundle" instead of several separate objects. For this purpose, a list would serve as well but see below for the differences between lists and environments.) With your call to getSymbols, four new objects are created:

"VMC" "VNO" "WAG" "WMT"

If these objects were created in your global environment (aka workspace), any pre-existing objects with the same names would be overwritten. (This happens when you use load ... for example, you have x in your workspace and also saved in a file named "x.rda". After load("x.rda") the previous version of x in your workspace is lost.)

Environments are not like ordinary R objects - because you can have different names pointing to the same environment. For example, if x is any kind of object in R, then assigning y <- x creates a copy of x. Not with environments:

> ls(data.env)
[1] "VMC" "VNO" "WAG" "WMT"
> yummy <- data.env
> yummy$x <- "bingo"
> ls(data.env)
[1] "VMC" "VNO" "WAG" "WMT" "x"  
> data.env$x
[1] "bingo"
> data.env$x <- "Florida"
> yummy$x
[1] "Florida"
> with(yummy, rm(x))
> ls(data.env)
[1] "VMC" "VNO" "WAG" "WMT"

Here when we assign yummy <- data.env we do not create a copy of data.env but just another pointer to the same object. So when we do something in yummy the same will happen in data.env.

How can we efficiently access members in data.env, e.g. if we want to check if all members in data.env are OHLC objects can we do something like: is.OHLC(data[[all elements]])?

As suggested above, eapply is the answer, - use unlist for converting the resulting list to avector if you like:

unlist(eapply(data.env, is.OHLC))

Finally, you can fetch the objects directly to your workspace like this:

getSymbols(tick,env=.GlobalEnv,src="yahoo",from=start)

This is probably not slower for most purposes but the downside is that you can't then easily access the four new objects together (for example, deleting them, or eapply'ing something). And you will have to make sure that you have nothing worthwhile in your workspace before you do it, because, potentially, everything can be overwritten.

lebatsnok
  • 6,329
  • 2
  • 21
  • 22
  • So an environmwnet is like a reference in c++? – math Apr 12 '14 at 18:21
  • I don't really know about references in c++. In R they say, environments use "pass-by-reference semantics" - and this is used in clever ways in e.g package `proto` as well as reference classes (see `?ReferenceClasses`) – lebatsnok Apr 12 '14 at 21:40
1

As Roman suggested the easiest method to check if a certain object in your data environment is an OHLC object is by using eapply like so:

eapply(data.env,is.OHLC)

which returns a list of your objects in your data environment and a logical value if it is a OHLC object or not. If you want to see a more compact form you can wrap "str" around the expression. For example to see which of the objects in my current data environment are OHLC-objects I can do the following:

> str(eapply(data,is.OHLC))
List of 9
 $ VXZlong        : logi TRUE
 $ prices         : logi FALSE
 $ XIVlong        : logi TRUE
 $ dates          : logi FALSE
 $ VXXlong        : logi TRUE
 $ weight         : logi FALSE
 $ ZIVlong        : logi TRUE
 $ symbolnames    : logi FALSE
 $ execution.price: logi FALSE
hvollmeier
  • 2,956
  • 1
  • 12
  • 17