For my work I often have to download official exchange rates. Thankfully the ECB publishes their reference rates in their Statistical Data Warehouse, and allows automatic download via an API.
I wrote a small R package to implement the API, and published it on github. Now, getting the latest rates for the USD is as easy as writing get_ecb_fx("USD").
In Analyse einer Barriere-Anleihe I was estimating the present value of a barrier bond emitted by Berliner Landesbank, which referred to the stock price of Daimler: The payout would be 100, if the price was either allways above the barrier of 70%, or, if it dipped below the barrier, but closed above the initial price at the maturity of the bond. In every other case, the buyer would get the value of the stock at maturity. For details on the bond, go here.
Using stochastic modelling on a 13 year history of the Daimler stock price, I estimated a present value at offering of 98.6% assuming a risk free rate of 2% for the 2 year maturity (I checked the sensitivity of the result to the risk free rate, but even at a -0.5% the mean present value is at 99.4%, so a slight loss).
Today I wanted to check what the actual payout would have been.
payoutEnd = function(basis, barriere, kurse)
{
basis = as.numeric(basis)
barriere = as.numeric(barriere)
kurse = as.numeric(kurse)
if(all(kurse >= barriere))
{
res = kurse[1]
} else if( last(kurse)>basis)
{
res = kurse[1]
} else
{
res = last(kurse)
}
return(res)
}
## [1] "DAI.DE"
Okay, so it seems the price never went below the barrier of 42.462, and the final payout was 100%:
payoutEnd(1,0.7, DAI.DE[,3]/DAI.DE[1,3])
## [1] 1
So, using hindsight, this would have been a good investment given the 7% coupon.
Lately I have been binge-watching Mythbusters, and one of the more curios myths they took on was the Monty Hall problem. The Monty Hall problem is named after a US TV show, were the candidate had the chance to win whatever price was behind one of three doors, where the other two doors had no price. The twist is that after the candidate choose, the moderator would show what was behind one of the other two doors, obviously one, where no price is, and the candidate now had the chance to switch the door.
Now, intuitively one would say that being shown what is behind a door will not change the chances, and the candidate has a 1 in 3 chance to win the price. Now the myth is, that switching the door will increase the chance to win substantially.
One might say, this is not really a myth, as it can be shown statistically to be true. But I am bad at combinatoric, so after seeing in Mythbusters how far ahead the switching strategy is, I wanted to redo their experiment as a Monte Carlo simulation.
First, we set up the experiment, and sample the winning doors, and the initial selection by the candidate.
## prices selected shown wins_stay wins_switch
## 1 2 1 NA NA NA
## 2 3 2 NA NA NA
## 3 3 2 NA NA NA
## 4 3 2 NA NA NA
## 5 1 1 NA NA NA
## 6 2 3 NA NA NA
Next, we define how the moderator has to choose, which door to show in each case. And this is the first hint to why the likelihood to win is higher if the candidate switches: We need to differ between the cases were the candidate chose the winning door or not, because in the case of the candidate choosing a losing door, the door to be opened by the moderator is predetermined – it’s the one which is not winning.
Following the switching strategy, the candidates chances are 2 in 3, which counter-intuitively is quite logical: The candidate will loose in each case where his initial selection was correct (1 in 3), but will win in each case where his initial selection was wrong (2 in 3).
Oh, and here is a nice clip explaining it much better:
One question a client asked was how rating migrations would effect their portfolio in the long term, and how to adjust the asset allocation to keep a stable average rating. As a small demo and proof of concept, I wrote a small shiny app. It allows you to adjust the portfolio weights based on the rating categories, the duration of the portfolio, and the growth rate of the portfolio.
Okay, as I wrote yesterday, ifelse is rather slow, at least compared to working in C++. As my current project is using ifelse rather a lot, i decided to write a small utility function. In the expectation that I will collect a number of similar functions, I made a package out of it and posted it on github: https://github.com/ojessen/ojUtils
I get a speedup of about 30 times, independent of the target type.
Feedback and corrections greatly appreciated.
Thanks to the people at Travis for providing a free CI server which works directly with github. This of course is a tiny example, but it is good to know that the workflow to set this up can be done in 5 minutes.
And thanks to Romain Fraoncois for showing some Rcpp sugar:
.@ojessen I sent you a pull request leveraging Rcpp’s ifelse. Although maybe wait: Rcpp’s ifelse is broken … https://t.co/38P0mQc3aZ