Peter Carl
http://www.braverock.com/~peter
> All,
>
> I suspect this topic/conversation is central to most of us -- and
> quite important to R and R-Finance in general.
>
> There are two primary issues that we seem to be encountering at this
> point in the R-Finance community:
>
> 1) consistency of design: so all of our work becomes additive.
> 2) generality: writing code that works in the most general case possible
>
> The first is quite difficult. I have personally been involved in
> *hundreds* of hours of productive (?) conversation with dozens of
> people on this topic, be it on the list, useR, NY, Meielisalp,
> R/Finance Chicago and back again at Meielisalp (and many sessions
> involving Jak's tap in Chicago). All of the conversations have been
> certainly valuable, though even after all of this I still can't figure
> out the best path...
>
> One thing that I have worked on personally is making consistency
> possible. 'xts' was born of this issue. We didn't need another
> time-series class. We had 9 or 10. We needed (or I needed) a way to
> abstract the class and just get the job done. 'xts' does that
> reasonably well -- though still far from complete. The same issue
> exists for portfolio level data, as well numerous other 'classes'.
>
> Everyone should be free to use their own data object, what would be
> nice (and required for maximum usefulness in my opinion) is if that
> choice wasn't imposed on the end-user to use your software. This
> leads to more users, more feedback, better code, and a more 'complete'
> landscape of tools that can be used.
>
> As a time series example -- xts lets the developer use one type of
> object (simplifying code), and accept *ALL* objects (simplifying the
> user experience).
>
> The point of the above is that interface counts, and it counts for a
> lot. If a framework is to work, it needs to be accessible to all
> users.
>
> The second point I'll toss out there is one of generality.
>
> This is just as difficult as the first conceptually, though I would
> argue possibly even more intractable. We just can't individually
> understand what we collectively require.
>
> quantmod set about in 2007 trying to create a 'framework' and has
> failed miserably. It does some things like data management and
> charting quite well, but the often asked question is how does
> specifyModel/buildModel/tradeModel work. The short answer is that it
> does, and it doesn't. It works on one type of strategy (EOD), and
> doesn't on others:
>
>> ?tradeModel
>> ## Not run:
>> m <- specifyModel(Next(OpCl(QQQQ)) ~ Lag(OpHi(QQQQ)))
>> m.built <-
>> buildModel(m,method='rpart',training.per=c('2007-01-01','2007-04-01'))
> loading required package: rpart
>>
>> tradeModel(m.built)
>
> Model: rpart1247761259.05370
>
> C.A.G.R.: 16.96% H.P.R.: 67.94%
>
> Returns by period summary:
>
> weekly monthly quarterly yearly
> Max. 12.29% 18.96% 21.12% 52.23%
> 3rd Qu. 2.43% 7.51% 8.84% 28.51%
> Mean 0.49% 2.10% 5.46% 20.50%
> Median 0.47% 0.78% 4.58% 4.80%
> 2rd Qu. -1.63% -3.01% 0.80% 4.63%
> Min. -8.89% -10.71% -4.87% 4.46%
>
> Period to date returns:
>
> weekly monthly quarterly yearly
> -0.44% 0.75% 0.75% 4.46%
>> tradeModel(m.built,leverage=2)
>
> Model: rpart1247761259.05370
>
> C.A.G.R.: 29.76% H.P.R.: 136.82%
>
> Returns by period summary:
>
> weekly monthly quarterly yearly
> Max. 25.22% 36.09% 36.23% 105.40%
> 3rd Qu. 4.72% 14.80% 17.59% 56.63%
> Mean 0.97% 4.05% 9.56% 39.50%
> Median 0.87% 1.46% 7.90% 7.90%
> 2rd Qu. -3.38% -6.20% 1.34% 6.57%
> Min. -17.15% -20.97% -10.30% 5.24%
>
> Period to date returns:
>
> weekly monthly quarterly yearly
> -0.95% 1.35% 1.35% 5.24%
>> ## End(Not run)
>
> Looks great! But it is useless. It is a casualty of specificity. A
> generalized framework would be awesome, but I think it is a much
> larger task than I can handle. I suspect that general to one person
> is fantastically restrictive to another.
>
> R is the 'general' framework.
>
> What we really need is consistency of the pieces that make
> building/testing models in *R* easier.
>
> This comes from projects like blotter I think. Were we can use parts
> that we want, and only those that we want.
>
> As I said at the start, this is a lot more involved than it looks
> like. Obviously best of luck to all who take up the challenge. This
> thread is an awesome start to the (larger) public conversation that
> has been taking place over beers for quite some time now.
>
> Best,
> Jeff
>
> On Thu, Jul 16, 2009 at 9:41 AM, Robert Sams<robert at sanctumfi.com> wrote:
>> Hi Mark,
>>
>> I have started a package called tradesys which, I think, is a clean
>> solution. The project is registered on r-forge
>> https://r-forge.r-project.org/projects/tradesys/ and the initial code
>> base with documentation will be checked-in by the end of the day London
>> time. As a taster:
>>
>>> library(tradesys)
>>> data(spx)
>>> tail(spx)
>> ? ? ? ? ? ? Open ? High ? ?Low ?Close ? ? Volume
>> 2009-05-12 910.52 915.57 896.46 908.35 6871750400
>> 2009-05-13 905.40 905.40 882.80 883.92 7091820000
>> 2009-05-14 884.24 898.36 882.52 893.07 6134870000
>> 2009-05-15 892.76 896.97 878.94 882.88 5439720000
>> 2009-05-18 886.07 910.00 886.07 909.71 5702150000
>> 2009-05-19 909.67 916.39 905.22 908.13 6616270000
>>> x <- tradesys(spx, el=MA(Close, 60) > MA(Close, 120), es=MA(Close, 60)
>> <= MA(Close, 120))
>>> tail(trades(x, uselog=TRUE))
>> ? ?phase ? ? ?etime ? ? ?xtime time nobs ?eprice ?xprice ? ?pnl
>> ror
>> 107 ? ?EL 2006-09-21 2007-09-12 ?356 ?244 1324.89 1471.10 146.21
>> 0.264117052
>> 108 ? ?ES 2007-09-12 2007-11-09 ? 58 ? 42 1471.10 1467.59 ? 3.51
>> 0.006027153
>> 109 ? ?EL 2007-11-09 2008-01-03 ? 55 ? 36 1467.59 1447.55 -20.04
>> -0.034689959
>> 110 ? ?ES 2008-01-03 2008-06-10 ?159 ?109 1447.55 1358.98 ?88.57
>> 0.159301490
>> 111 ? ?EL 2008-06-10 2008-07-21 ? 41 ? 28 1358.98 1261.82 -97.16
>> -0.187159273
>> 112 ? ?ES 2008-07-21 2009-05-19 ?302 ?209 1261.82 ?909.67 352.15
>> 0.825619186
>>> tail(equity(x, uselog=TRUE))
>> ? ? ? ? ? trade states ? ?delta ? ?price ? ? ? ? ?ror ? equity
>> 2009-05-12 ? 112 ? ? -1 1.331220 6.814016 ?0.018107970 38.02601
>> 2009-05-13 ? 112 ? ? -1 1.307543 6.808377 ?0.007373275 38.30638
>> 2009-05-14 ? 112 ? ? -1 1.297973 6.784729 ?0.030694874 39.48219
>> 2009-05-15 ? 112 ? ? -1 1.259318 6.794318 -0.012075942 39.00541
>> 2009-05-18 ? 112 ? ? -1 1.274712 6.786796 ?0.009588169 39.37940
>> 2009-05-19 ? 112 ? ? -1 1.262606 6.813082 -0.033188777 38.07244
>>
>> Please checkout and play with the code at your leisure. Anyone
>> interested in write-access to the repository should contact me directly.
>>
>>
>> Robert
>>
>>
>> ________________________________
>>
>> ? ? ? ?From: r-sig-finance-bounces at stat.math.ethz.ch
>> [mailto:r-sig-finance-bounces at stat.math.ethz.ch] On Behalf Of Mark
>> Breman
>> ? ? ? ?Sent: 16 July 2009 15:15
>> ? ? ? ?To: r-sig-finance at stat.math.ethz.ch
>> ? ? ? ?Subject: [R-SIG-Finance] Backtesting trade systems
>>
>>
>> ? ? ? ?Hello,
>>
>> ? ? ? ?I have spend quit some time now looking for a package that
>> allows me to backtest (technical) trading systems based on single
>> financial instruments with R.
>>
>> ? ? ? ?I had a look at Rmetrics, blotter, fTrading,
>> PerformanceAnalytics, backtest, quantmod, TTR etc, but not one of these
>> fill my requirements. It's not that they are not usefull, on the
>> contrary, they are all filled with terrific statistical stuff, but it's
>> not the simple, practical and straightforward approach that I am looking
>> for as a trader rather than as a statisticus.
>>
>> ? ? ? ?So I have decided to build my own solution, reusing as much as
>> possible from these existing packages. (As a former software engineer I
>> know how much time and effort goes into buiding reliable software, so
>> the more reuse the better). As I am quite new to R and statistics in
>> general, there is a lot to learn for me here...
>>
>>
>> ? ? ? ?What I have build so far is a very basic set of functions called
>> "tradesim.R" (I have attached it to this post). A very basic example of
>> how these functions can be used for a backtest-run can be found in
>> "tradesim_example.R". The example runs a backtest with end-of-day data
>> from AAPL, using a (rather poor) trading system based on the RSI
>> indicator (from the TTR package).
>>
>> ? ? ? ?Now I have read in some older post on this list that others were
>> also searching for a backtesting package. I even read a post proposing
>> to start a group effort creating such a package. I suspect that some of
>> you might be interested in what I made so far and maybe would like to
>> put in a effort creating such a package together. I certainly know that
>> it's a lot easier to create good software as a group, rather than by a
>> single person...
>>
>> ? ? ? ?So if you are interested have a look at what I got so far and
>> let me know what you think.
>>
>> ? ? ? ?Regards,
>>
>> ? ? ? ?-Mark-
>>
>>
>>
>> _______________________________________________
>> R-SIG-Finance at 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 at insightalgo.com
>
> ia: insight algorithmics
> www.insightalgo.com
>
> _______________________________________________
> R-SIG-Finance at 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.
>