Calculating DV01 using futile.paradigm

Here’s a short example of using the futile.paradigm for calculating the DV01 of a bond. The basic idea is to layout the type definitions and then create the functions to do the calculations.

require(futile.paradigm)

create.Bond <- function(T, par, coupon, yield, periods, freq)
{
  list(par=par, coupon=coupon, yield=yield, periods=periods, freq=freq)
}

# Inherit from the Bond type
create.SemiBond <- function(T, par, coupon, yield, periods, freq=2)
  create(Bond, par, coupon, yield, periods, freq)

price.bond %when% (bond %isa% Bond)
price.bond <- function(bond) price(bond, bond$yield)

price.bondy %when% (bond %isa% Bond)
price.bondy <- function(bond, r)
{
  r <- r / bond$freq
  n <- bond$periods
  coupon(bond) * (1 - (1+r)^-n) / r + bond$par * (1+r)^-n
}

dv01.bond %when% (bond %isa% Bond)
dv01.bond <- function(bond)
{
  y1 <- bond$yield - 0.0001
  y2 <- bond$yield + 0.0001
  p1 <- price(bond, y1)
  p2 <- price(bond, y2)
  - (p1 - p2) / (y1 - y2) / 100
}

The helper functions below show some of the power of guards. Depending on the value of a field, a different function variant can be called for the coupon calculation. (Note that this is used for illustrative purposes and would break down in the current ZIRP world.)

# When coupon is in percentage terms
coupon.pct %when% (bond %isa% Bond && bond$coupon < 1)
coupon.pct <- function(bond) bond$par * bond$coupon / bond$freq

coupon.dollar %when% (bond %isa% Bond)
coupon.dollar <- function(bond) bond$coupon / bond$freq

The code can be run by executing the below snippet.

> b <- create(SemiBond, 100,3.5, 0.035, 10)
> dv01(b)
[1] 8.376442

Configurable server properties now available in bunny_farm

The bunny_farm library now uses application environment variables for setting the server connection properties. This has been on the todo list for quite some time, but as my system is still in development, there wasn’t a huge urgency to make this configurable. The time though has come, so without further ado, the following properties can be set in the app.config:

{amqp_username, <<"guest">>},
{amqp_password, <<"guest">>},
{amqp_virtual_host, <<"/">>},
{amqp_host, "localhost"},
{amqp_port, "5672"}

These need to be set in the properties for the application of the calling process. Since bunny_farm itself doesn’t start any processes itself, the config should be in the application of the calling process. This also gives more flexibility since multiple applications can each own their own server configuration.

bunny_farm updated with queue-based gen_server and gen_fsm

The bunny_farm library now includes two queue-based implementations of generic server behaviours. They are named gen_qserver and gen_qfsm, which should be self explanatory. By using these behaviours, all queue semantics are built-in and hidden from view. This means that module developers can focus on building modules and not worrying about details related to bus communication.

Messages sent over the bus behave like erlang messages with both asynchronous and synchronous semantics. The connections to the message queue are configured when the process is started with an additional parameter passed to start_link and init.

Connections

Exchanges used for publishing only need an exchange defined as either

• <<”exchange”>>
• “exchange”

The string form will be converted to a binary string, but the handle (for retrieving the connection later) will remain as a string.

For consuming messages, both an exchange and a routing key must be provided. When the server starts, it will automatically consume messages for these connections and deliver messages using the callbacks defined below.

• {<<”exchange”>>, <<”routing.key”>>}
• {“exchange”, “routing.key”}

The RabbitMQ connection specs are then passed to gen_qserver:start_link.

start_link() ->
  ConnSpecs = [ <<"pub.1.exch">>, <<"pub.2.exch">>, {<<"sub.1.exch">>, <<"key.1">>} ],
  gen_qserver:start_link(?MODULE, [], [], ConnSpecs).

The init/2 callback has an additional argument that represents the pid for the cache process, which maintains the queue connections. These can be retrieved in code as

Bus = qcache:get_bus(CachePid, <<"pub.1.exch">>),
bunny_farm:publish("my message", <<"route.2">>, Bus),

Obviously to use the CachePid, it needs to be saved in the implementation’s state. If a server only receives messages, then this argument can be ignored.

gen_qserver

These servers dispatch to handle_cast/2 and handle_cast/3 as shown below.

• publish -> handle_cast/2
• RPC -> handle_call/3

gen_qfsm

These servers dispatch to Module:StateName/2 and Module:StateName/3 as shown below.

• publish -> Module:StateName/2
• RPC -> Module:StateName/3

Messages from the queue are wrapped in a tuple so that pattern matching can be done on the routing key. The format is: { RoutingKey, Payload }, where Payload is equivalent to the standard message body that gets sent to the callback. Hence if you don’t about the special routing, all messages can be passed through via an implementation like this:

handle_cast({<<_B/binary>>, Payload}, State) ->
handle_cast(Payload, State);

More examples will follow.

Git pull with https

I recently had the pleasure of working in a new space where normal git was blocked by a firewall. So I enabled SSL on my git server and modified my remote URLs to point to the new address. When I tried to pull, I got this gem:

brian$ git pull
error:  while accessing https://git.somedomain.com/project.git/info/refs

fatal: HTTP request failed

In fact even from a different location, the same thing happens. So what’s that up? The short of it is that git will attempt to verify SSL certificates and if that verification fails, you git the vague error above. Since I’m too cheap to use a paid CA, this situation applies to me. Thankfully the solution is straightforward. Just export the following environment variable and you’re set.

export GIT_SSL_NO_VERIFY=true

Now if only that error message were a bit more obvious.

Comparing ?assertMatch versus a match expression in eunit

Tags

erlang, eunit

There are a lot of examples of how to use eunit. Some use a match expression, which is a concise “built-in” way to wire up some tests. On the other hand, eunit provides the macro ?assertEqual to perform a match test. What’s the difference? It’s deeper than cosmetics and boils down to how much information you need on failure.

The example below is from real code with names changed to protect the guilty.

Match Expression

Using a pattern matching expression only gives the bare minimum error on a failed test. This is probably fine for simple tests.

true = CanDance.
    dance_manager_tests: main_test_...*failed*
::error:{badmatch,false}

Explicit Assertion

Using the macro gives much more color, which I prefer since it tells me where and what the error is.

?assertEqual(true, CanDance).
    dance_manager_tests: main_test_...*failed*
::error:{assertEqual_failed,[{module,dance_manager_tests},
                           {line,30},
                           {expression,"CanDance"},
                           {expected,true},
                           {value,false}]}
  in function dance_manager_tests:'-can_dance_false/0-fun-0-'/2