**Milk Trader**, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

I have a knife rack on my kitchen wall with all my kitchen knives easily identifiable and accessible. I also have small scars on my hand where each knife can claim to have left a mark. Itâ€™s not the knifeâ€™s fault, of course. They hardly like being suddenly dropped and cursed at. They have no control over who gets picked on a given day. The choice is really mine.

Whatâ€™s good in the kitchen is good at the trade desk. We like choice as traders. We choose markets, trading styles and excuses for our sub-optimal performances. On those occasions when we need to crunch some numbers, we also like some choice. More than any other curve-fitting software, R is best suited for trading precisely because of its â€śquoteâ€ť â€“ diversity.

In fact, Iâ€™m sure this is on purpose. The Unix geniuses did a lot of thinking about software design and architecture when they designed their operating system. They even came up with a set of rules, one of which is the Rule of Diversity. This states that one must distrust all claims to one true way.Â Many commercial packages cannot do this of course, as they are confined to a monolithic vision of how things get done. R does this well.

This is a double-edged kitchen knife though and some care must be taken when choosing what tool you want to use for preparing your algorithm mis-en-place. Suppose youâ€™re interested in calculating price changes for your favorite, useless metal, silver. Price change or percentage change? Already with the choices. We are going to use percentage change over price change for our illustration of Râ€™s diversity.

Weâ€™ll keep it simple and get the daily closing prices of the silver ETF known as SLV, managed by JP Morgan of course, and isnâ€™t that ironic? In any case, weâ€™ll avoid the crazy split that happened back in 2007 and just get the prices for the year 2010. Iâ€™m going to require three packages in this example, Jeff Ryanâ€™s quantmod,Â Joshua Ulrichâ€™s TTR and Brian Petersonâ€™s PerformanceAnalytics. TTR actually automatically loads with quantmod (as does xts and zoo) so you donâ€™t need to specify it. But Iâ€™m going to do it anyway. Weâ€™ll illustrate diversity right from the get go.

Now we get the SLV prices into our environment. Two ways. I usually donâ€™t give the functionâ€™s surname, but I will for now because it adds clarity later on.

quantmod::getSymbols(â€śSLVâ€ť)Â #getSymbols(â€śSLVâ€ť) is equivalent

Now to simplify our demonstration of returns, letâ€™s index out the closing price only, and look at prices forÂ 2010.

SLV <- SLV[â€ś2010â€ť]

There are several permutations of that approach that are suitable, and probably some that arenâ€™t suitable but still work. Here is the head of data that we have as a result:

2010-01-04Â Â Â Â 17.23

2010-01-05Â Â Â Â 17.51

What?!? Silver was trading at $17?Â I could have gotten it that cheap and now itâ€™s trading what, north of $45? Itâ€™s like Netflix, Amazon and Lulu. Combined. And I was going to get a gazillion sleeves from the Maple coin makers north of the border. Well, itâ€™s too late now. Isnâ€™t it. But I digress.

Now we set ourselves upon the task at hand. To calculate the percent change from one day to the next. I know everyone loathes to do it this way, and would much rather calculate the actual dollar and cents amount change, but percent returns are more tractable when we decide to get serious about our statistical pursuits. Iâ€™m going to use the default settings for four functions for the illustration. And each one will populate itâ€™s own epynomous column in our matrix.

SLV$DeltÂ Â Â Â Â Â Â Â Â Â Â <- quantmod::Delt(Cl(SLV))Â Â

SLV$dailyReturnÂ Â Â Â Â <- quantmod::dailyReturn(Cl(SLV))

SLV$ROCÂ Â Â Â Â Â Â Â Â Â Â Â Â <- TTR::ROC(Cl(SLV))

SLV$CalculateReturns <- PerformanceAnalytics::CalculateReturns(Cl(SLV))

Now, the head of our data again:

Â Â Â Â Â Â Â Â Â SLV.CloseÂ Â Â Delt Â dailyReturn Â Â Â Â Â ROCÂ CalculateReturns

2010-01-04Â 17.23Â Â Â Â Â NAÂ Â 0.000000000 Â Â Â Â Â NA Â Â Â Â Â Â Â Â Â Â Â NA

2010-01-05Â 17.51 0.016250725 Â 0.016250725Â 0.016120096Â Â Â Â Â 0.016120096

Alright, well we certainly have diversity donâ€™t we? Letâ€™s take one line at a time. For January 4, 2010, only dailyReturn put a value in that row, and the others returned NA. And for January 5, 2010, we have Delt and dailyReturn with the same number, but different from the number that ROC and CalculateReturns share. Hmmm. As it turns out, there are two schools of though on this topic. Do you want simple returns, where you simply take yesterdayâ€™s price minus todayâ€™s price and divide it by yesterdayâ€™s price, or do you want the log of that equation? Log, youâ€™re kidding right? No actually logarithms are no joking matter. There will be no laughter when logarithms come into the room to perform their magical tricks. Only awe.

Natural logarithms of returns are nice because you can add them up in their log-ness and then take the result and un-log it to get the correct result. That result being the total percent change from one date to the other. This comes in handy for calculating a monthly or annual return. Try it out yourself, itâ€™s quite cool actually. Donâ€™t forget to un-log though, by way of the exp(my_log_return) function.

You cannot add simple returns, but must multiply them. If your column has zeroes in it, well we have a problem that the add folk donâ€™t need to deal with.Â I like logs better, even though you have to put your returns into a spacesuit on a temporary basis.

Each function has a default on this issue and an option to change it to the other way of doing things. Here is a truncated parameter list for each function. Notice the diversity in how we define simple returns versus logarithmic returns.

Delt(x1,type = c(â€śarithmeticâ€ť, â€ślogâ€ť))

periodReturn(x, type=â€™arithmeticâ€™) # log would be â€ślogâ€ť

ROC(x, type=c(â€ścontinuousâ€ť, â€śdiscreteâ€ť))

CalculateReturns(prices, method=c(â€ścompoundâ€ť,â€ťsimpleâ€ť))

This adds up to more thinking on your part in the end, but youâ€™ll be fine. Make yourself a sandwich and begin contemplation at your leisure. Just donâ€™t cut yourself while doing it.

**leave a comment**for the author, please follow the link and comment on their blog:

**Milk Trader**.

R-bloggers.com offers

**daily e-mail updates**about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.