Skip to content

Blotter package - problem with example.

5 messages · kafkaz, Brian G. Peterson

Original
kafkaz
# 
Brian,
I tried demo('longtrend') and the result is:

# Load data with quantmod
[1] "Loading data"
Error in eval.with.vis(expr, envir, enclos) : 
  could not find function "currency"
In addition: There were 11 warnings (use warnings() to see them)

My problems started, then I tried to add a new transaction:

addTxn(portfolio, "SPY", '2007-01-03', 50, 96.5, -0.05*50) 
[1] "2007-01-03 SPY 50 @ 96.5"
Warning messages:
1: In getInstrument(Symbol) :
  Instrument SPY  not found, please create it first.


I debugged a bit and I found, that getInstrument function fails on this
line:
if (inherits(tmp_instr, "try-error") | !is.instrument(tmp_instr)) {

I suspect, that FinancialInstrument package isn't committed properly.
Currency, stock methods
do not exist in my environment. The version of FI is 0.02, blotter v.0.4

As well, I have noticed, that environment variables are used very heavily.
What is the reason of using
environment variables instead of local variables? For example, in initPortf
method:
if (exists(paste("portfolio", name, sep = "."), envir = .blotter, 
        inherits = TRUE))
I found it frustrating, when I tried to recreate a portfolio and an account,
but I couldn't.

Thanks,
kafka
Brian G. Peterson
#
kafkaz wrote:
<...>
Yes, I tried using @alias tags (getting fancy) in the documentation, and 
it messed up the NAMESPACE file.  Sorry.

This was fixed in revision 270 a couple of days ago, which looks like 
it's available as prebuilt packages on R-Forge now.

updating FinancialInstrument should fix this.
getPortfolio() and getAccount()

will let you examine the Portfolio and Account objects by providing 
local copies in the global environment.

The primary reason for using the environment is performance.  By using 
get() and assign() we can minimize unnecessary copying as things are called.

The secondary (but important) reason for using environment variables 
instead of local (passed) variables is that we need to maintain control 
over the objects.  By putting them in an environment, they don't clutter 
the global environment, and we have a reasonable belief that only expert 
users will 'touch' the objects themselves.

The tertiary reason is that we expect that these objects and/or their 
methods will probably get reimplemented in C/C++ at some point, and will 
not necessarily remain as pure R code for performance.  We've (mostly) 
stabilized the API and function calls, so those should (mostly) remain 
the same (I'm relying on this code on real portfolios at this point) but 
the 'internals' may change as we optimize the execution.

Regards,

  - Brian
kafkaz
# 
I tried to run this:
install.packages("FinancialInstrument",
repos="http://R-Forge.R-project.org")
result is the same.

Concerning variable's question I'm convinced. But how do I clean up after
using blotter?
Brian G. Peterson
#
kafkaz wrote:
restart R after doing this.  I was just able to update one machine here 
using the metohd you describe, and got the current revision of 
FinancialInstrument from R-Forge, so you should too.
The demo's clean up at the start so that you can run them multiple times.

Look at how the demos remove objects in the environment namespace.

Regards,

    - Brian
kafkaz
# 
Got another error:

updateAcct("aaa", Dates = as.Date(index(SPY.monthly[length(SPY.monthly)])))
Error: object 'CurrentSpan' not found
In addition: Warning message:
In max(i) : no non-missing arguments to max; returning -Inf

My proposal would be to implement the methods like
removeAccount/removePortfolio. 
My dirty solution:
rm(list=ls(envir=.blotter),envir=.blotter)
try(rm("ltaccount","ltportfolio","ClosePrice","CurrentDate","equity","GSPC","i","initDate","initEq","Posn","UnitSize","verbose"),silent=TRUE)