Oljefondets begrepsforvirring

Oljefondet har hatt en “aktiv avkastning” på 0,3 % i året. Fondet har imidlertid ikke hatt meravkastning av betydning. Forvirret? Det har du grunn til å være. 

Begrepet “aktiv avkastning” betyr at avkastningstallene ikke risikojusteres slik lærebøkene anbefaler. Begrepet dukket opp i en rapport fra 2009 skrevet av tre meget kompetente professorer for finansdepartementet i 2009. I en ny rapport av Ang, Brant og Denison er begrepet videreført slik at fondets prestasjoner måles uten å kontrollere for risiko.

Risiko er viktig. En skihopper som velger lavere avsats får kompensert i form av ekstra meter. På samme måte må avkastning justeres for risiko for at prestasjonene til fondsforvaltere skal være sammenlignbare.

Det er imidlertid ikke all risiko som er relevant. IT-selskapet Birdstep Technology er en høyrisikoaksje. Den har hele fem ganger mer risiko enn DNB-aksjen. Overaskende nok er det likevel DNB-aksjen som gir deg høyest forventet avkastning. Forventet avkastning for DNB-aksjen er godt over det dobbelte av Birdsteps.

Årsaken er at investorene ikke bryr seg så mye om Birdsteps risiko. Denne aksjen beveger seg nemlig helt i utakt med de andre selskapene på børsen. For DNB-aksjen er det motsatt. Den følger børsens bevegelser nesten slavisk.

For en investor er DNBs risiko farlig. Når det går dårlig med DNB går det sannsynligvis dårlig med resten av porteføljen. Dette kalles markedsrisiko, og investorer liker det ikke. For å tiltrekke seg investorer må DNB-aksjer derfor levere en avkastning som er betydelig bedre enn Birdsteps.

Markedsrisikoen måles med “Beta”. Børsindeksen har en beta identisk lik én. Betaen er større enn én for selskaper med mye markedsrisiko, slik som DNB. Birdstep har en veldig lav beta på bare 0,54.

Oljefondet har en beta på 1,06 for hele fondet. Fondet har dermed tatt mer risiko enn markedet, noe som forklarer det meste av fondets meravkastning på 0.2 % etter kostnader. Den risikojusterte avkastningen er derfor omtrent lik null.

Egentlig skal fondet ha en beta lik én, slik som markedet. Årsaken til den høye betaen finner vi i en tabbe fondet gjorde før finanskrisen.

Fondets obligasjonsportefølje følger en indeks som domineres av relativt sikker statsgjeld. Avkastningen er imidlertid mye bedre for selskapsobligasjoner. Fondet bestemte seg derfor for å forsøke å høste denne gevinsten. I gode tider er det liten forskjell på selskapsobligasjoner og statsobligasjoner, så ingen utenfor fondet la merke til dette.

Når et selskap begynner å få økonomiske problemer begynner imidlertid obligasjonene å ligne mer og mer på aksjer. Da finanskrisen slo inn ble den trygge obligasjonsporteføljen dermed veldig utsatt for svingninger i aksjemarkedet.

Finanskrisen avslørte dermed at fondet hadde brukt obligasjonsporteføljen til å høste en risikopremie. Fondet la selv helt om på forvaltningen av obligasjonsporteføljen etter krisen, så det er klart at smellen også kom overraskende på fondet.

Å høste risikopremier er helt legitimt, men vi må vite om det. Det er også viktig å være klar over at det ikke trengs noe som helst kyndighet, dyktighet eller talent for å slå markedsindeksen ved å ta markedsrisiko.

Derfor blir det helt feil å ikke kontrollere for risiko. Det er full konsensus innen akademia om at dyktighet skal måles ved å risikojustere avkastningen. Selv professorene bak rapportene er enige i det. De mener likevel at når fondet tar mer risiko enn markedet, så er det en aktiv beslutning. “Aktiv avkastning” er ment å være et mål på det.

Feilgrepet som ble avslørt av finanskrisen viser hvor galt et slikt resonnement kan føre avsted. Med “aktiv avkastning” som prestasjonsmål forvandles fadesen på et merkelig vis til en bragd.

Dette er problematisk av to grunner.

  • For det første blir incentivene store til å ta mer risiko enn markedet på måter som ikke er lett å oppdage. Fondet må gjerne forsøke å høste risikogevinster. For å unngå nye tabber må det imidlertid gjøres i åpenhet. Resultatene bør rapporteres separat slik at omverdenen vet hva som foregår og slik at eventuelle nye feilsteg gjøres med åpne øyne. 
  • For det andre bruker fondet sin “aktive avkastning” på 0,3 % til å argumentere for mer aktiv forvaltning. Faktum er at fondet samlet ikke har klart å levere meravkastning av betydning. De samme resultatene kunne vært oppnådd med en passiv strategi.

Create an iphone application using xcode that dynamically creates sqlite tables

This tutorial will try to create an iphone application that will dynamically create tables in sqlite database. This tutorial will use anime information for example.

Note that this tutorial is not for beginner, I'll just summarized the steps and provide the github repository for the project.

Prerequisite:
1.) You should look at the code in my todo list tutorial before this one.
2.) Create an anime sqlite database using your preferred tool, I've used SQLite Manager plugin for firefox.

Steps:
1.) Create a new empty ios project.

2.) Select the project, and in the general tab under Linked Frameworks, add libsqlite3.0.dylib.

3.) Add the sqlite database we've created, right click on the project folder click Add Files..., then select the anime.sqlite file and check "Copy items into destination...". Now we have the database inside our project.
Your project should look like:

4.) Create the main story board inside the SqliteAnimeDb folder.

5.) In the project setting set the main interface to the story board we've created.

6.) Comment these 3 lines in the AppDelegate class:
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
// Override point for customization after application launch.
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];

7.) I'll let the code explain but I'm attaching the 2 views I've created for demo.

In this view we display the list of anime titles with author subtitle. Clear and reload do the functions respectively on the database. + will navigate to the next view.


This view is where we add an anime object.

Note:
KBSSqliteConnection, is the class where we put the sqlite database operations like create table, open db, insert record, etc.

Github repository:

My Todo List iphone application development using xcode

This tutorial will create a Todo list iphone application using xcode. This is the same tutorial in the apple's website I've specified in the reference link below.

Note that this tutorial is not for beginner, basically I'll just summarized what I did and provide the github repository.

To summarize what I did:
1.) In AppDelegate class, I removed the window definition.
2.) Create a Main story board.
3.) Set the default Main Interface in the project setup, this is the story board we've created in #2.
4.) Add a tableViewController and viewController in the story board.
5.) Create your Todo item object.
6.) Create a customized class for the 2 components we've created at #4.
7.) Code the methods :-)

The source code is available at:
https://github.com/czetsuya/MyTodoList

Reference:
https://developer.apple.com/library/iOS/referencelibrary/GettingStarted/RoadMapiOS/index.html#//apple_ref/doc/uid/TP40011343-CH2-SW1

How to change varchar to nvarchar in mssql using hibernate

In my recent assignment I was asked to change how hibernate creates a table changing varchar fields to nvarchar. The problem is in MSSQL we need an nvarchar to support UTF-8 characters.

We are actually using a JDBC MSSQL driver available here:
http://technet.microsoft.com/en-us/library/ms378422.aspx

This driver needs to be configured inside jboss, the server I'm on.

First you need to extend SQLServerDialect and override the VARCHAR definition.
package org.kbs.hibernate.dialect;

import java.sql.Types;

import org.hibernate.HibernateException;
import org.hibernate.dialect.SQLServerDialect;

public class MSSQLServerDialect extends SQLServerDialect {

public UnicodeSQLServerDialect() {
super();

registerColumnType(Types.VARCHAR, "nvarchar($l)");
registerColumnType(Types.BIGINT, "bigint");
registerColumnType(Types.BIT, "bit");
}

}

Second you need to tell hibernate to use your new class:
<property name="hibernate.dialect" value="org.kbs.hibernate.dialect.MSSQLServerDialect" />

Reference:
http://grepcode.com/file/repo1.maven.org/maven2/org.hibernate/hibernate-core/3.3.1.GA/org/hibernate/dialect/SQLServerDialect.java

How to get around OptimisticLockException or StaleObjectStateException

The 2 errors above are common specially when dealing with a multi-threaded application. For example in my case I have several rabbit mq listeners. For those that are not familiar with it, it's a server where one language can send a message to be consumed by another but not limited to that. For example communication between .net and java.

This multi-threaded application access a set of web services that update parts of a database. The problem is messages arriving in the rabbit mq bus are asynchronous and are not really aware of each other. So there might be a time that 2 different requests that access the same part of a database at the same time.

Working with this I've remembered 2 different solutions plus I've learned another one:

1.) Using synchronized keyword in a method. This is what I've used, because fortunately all my web service calls are in a single class. Basically it locks the method and only 1 thread can access the method at a time.
public synchronized ClientResponse syncWebServiceCall(
WebResource webResource) {
// code here
}

2.) The next is a statement block, similar to no 1 except that you used a mutex object to lock. The mutex object can be the object where the method is defined or another object. In this way we don't necessarily lock the whole method.
public ClientResponse syncWebServiceCall(
WebResource webResource) {
synchronized(this) {
// code
}
}

3.) The last one. Which I've just learned. Using ReentrantLock: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html Modifying the example:
class X {
private final ReentrantLock lock = new ReentrantLock();

public ClientResponse syncWebServiceCall() {
lock.lock(); // block until condition holds
try {
// ... method body
} finally {
lock.unlock()
}
}
}

Feil om oljefondet

Det er ikke riktig slik Øystein Børsum påstår i en kronikk i onsdagens DN, at oljefondet har slått indeksen med 0,3 % i året. Dette tallet er ikke justert for den ekstra risiko som fondet har påtatt seg. Fondet har ikke hatt noen risikojustert meravkastning. Beregningene som viser dette kan lastes ned her.

Som jeg har skrevet om tidligere, så skyldes den negative meravkastningen antakeligvis at fondet tok for mye risiko før finanskrisen. Spesielt gjaldt dette renteinvesteringene. Før finanskrisen ble renteinvesteringene brukt som en gigantisk spekulasjonskasse. Brutto belåning var på nesten hundre prosent, hvilket indikerer enorme veddemål på rentedifferanser. Dette skjedde innenfor noen rammer som politikerne trodde var ganske stramme. 60 % skulle investeres i “trygge” obligasjoner. Fondet brukte det til spekulasjon.

Denne historien viser tydelig at å gi for store fullmakter til forvalteren kan være svært risikabelt. Dersom ønsket er en trygg forvaltning av oljeformuen, er mer aktiv forvaltning og videre fullmakter neppe vegen å gå.

Børsum har rett i at det finnes noen premier der som fondet kan høste. Problemet er at ingen vet sikkert om disse premiene er gavepakker til de langsiktige investorene eller betaling for en eller annen type risiko. Det kan hende at vi ikke bør bruke oljefondet til å finne ut av det.

Fondet har nå drevet i 16 år uten at vi ser noen samlet gevinst av den aktive forvaltningen. Kanskje det er på tide å gi seg?

For mye olje i oljefondet

Norge er i dag overinvestert i oljeindustrien og kunne redusert landets samlede eksponering ved å ekskludere oljeaksjer fra oljefondet. Finansdepartementet har imidlertid tidligere forsvart at oljefondet skal være investert i oljeselskaper og i Stortingsmelding 19 for 2013-2014 argumenteres det også for dette.

I lørdagens DN har Bård Bjerkholt en interessant kommentar der han, i likhet med Finansdepartementet, konkluderer med at de faglige argumentene ikke støtter nedsalg.

Konklusjonen bygger blant annet på at verdien av olje- og gassreservene visstnok bare utgjør fire prosent av nasjonalformuen. Norges økonomi er altså ikke så veldig avhengig av oljenæringen. Dette vil nok komme som en overraskelse på de fleste, så kan det være sant? Svaret er nei.

Verdien av oljereservene beregnes ut fra differansen mellom oljepris og utvinningskostnad. I kostnadene ligger imidlertid mye nasjonal verdiskaping. Tall fra SSB viser at 2,3 % av arbeidskraften og 16 % av realkapitalen går med til oljeproduksjon. Tar vi med dette, øker oljenæringens andel av nasjonalformuen til åtte prosent med departementets tall. SSB har tidligere beregnet at olje og gass utgjør 12 % av formuen.

I tillegg kommer ringvirkninger fra 70 milliarder i årlige lønnsutbetalinger, slik at den samlede eksponeringen lett kommer godt over 10 % av nasjonalformuen.

Oljeindustrien utgjør om lag 9 % av den globale markedsporteføljen. Statens investering i Statoil på 7 % av oljefondet kan dermed alene forsvare et nedsalg av fondets oljeaksjer.

Risikospredning betyr at vi kan redusere risikoen uten at det går utover avkastningen. Det er det nærmeste vi kommer gratis lunsj i finansmarkedet. At Finansdepartementet ikke har lyst på den er helt greit, men faktagrunnlaget bør jo være riktig.

How to catch a ConstraintViolationException in JavaEE

The following piece of code catch a ConstraintValidationException in JavaEE so that we will be able to display an appropriate message to the user instead of a long stack trace.


try {
//perform a transaction operation here, perhaps a delete
} catch (EJBTransactionRolledbackException e) {
Throwable t = e.getCause();
while ((t != null) && !(t instanceof ConstraintViolationException)) {
t = t.getCause();
}
if (t instanceof ConstraintViolationException) {}
}

As you can see we catch EJBTransactionRolledbackException, why  not ConstraintViolationException? Trust me it will not work because that exception is already wrapped by the container, so to be able to process it we need to unwrap it again.

Create a custom json string deserializer in java

On normal cases we really have a lot of ways in doing so, we can use jaxb, jackson and more.

But in some cases we really need to improvised, for example in the project I'm working right now I have a date string from a .net application in this format: "2014-04-08T07:08:48.1344874Z". As you can see it has 7 characters in the millisecond section, while java normally use 3. Of course you'll say just use a simpleDateFormat that will parse the 7 characters, I've thought of that and here's the result

SimpleDateFormat df1 = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSSSSSX");
Date d1 = df1.parse("2014-04-07T15:20:40.7439627Z");
System.out.println("D1: " + d1); // produces "Mon Apr 07 19:24:39 CEST 2014"

//as I said it works on 3 character millies
SimpleDateFormat df2 = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX");
Date d2 = df2.parse("2014-04-07T15:20:40.743Z");
System.out.println("D2: " + d2); // produces "Mon Apr 07 17:20:40 CEST 2014"

Note that I'm using UTC+2.

I found a solution that is worth mentioning, although it didn't really work 100% for me. Normally when you generate classes from xsd using xjc, it will use an XmlGregorianCalendar object. So the first problem is how will I convert it to a Date object?

1.) Create a xs:dateTime binding, xs:dateTime is what you'll see in your xsd.
<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

<globalBindings>
<javaType name="java.util.Date" xmlType="xs:dateTime"
parseMethod="org.czetsuya.xsd.converter.XsdDateTimeConverter.unmarshal"
printMethod="org.czetsuya.xsd.converter.XsdDateTimeConverter.marshalDateTime" />
<javaType name="java.util.Date" xmlType="xs:date"
parseMethod="org.czetsuya.xsd.converter.XsdDateTimeConverter.unmarshal"
printMethod="org.czetsuya.xsd.converter.XsdDateTimeConverter.marshalDate" />
</globalBindings>

</bindings>

2.) Generate the java class from xsd, I normally do it via eclipse using the jaxb converter from jaxb schema to java class.

What it does is create a JavaType adapter and replace XmlGregorianCalendar with a date object. The xs:dateTime fields will be annotated like this:
@XmlJavaTypeAdapter(Adapter1 .class)
@XmlSchemaType(name = "dateTime")
protected Date myDate;

And it will work, and so I thought but it did not :-) Same problem I describe earlier. Btw, I'm using jackson ObjectMapper to parse a json string into an object like this:
ObjectMapper mapper = ObjectMapperFactory.createObjectMapper();
messageWrapper = mapper.readValue(message, MyClass.class);

That code successfully parsed my json string but the date values are still totally wrong no matter the data type.

And so the final part of the solution. Customizing a Json de-serializer for object of type Date. See our XmlGregorianCalendar to Date comes into place.

So our converter:
package org.czetsuya.xsd.converter;

import java.io.IOException;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.GregorianCalendar;

import javax.xml.bind.DatatypeConverter;

import org.apache.log4j.Logger;
import org.codehaus.jackson.JsonParser;
import org.codehaus.jackson.JsonProcessingException;
import org.codehaus.jackson.map.DeserializationContext;
import org.codehaus.jackson.map.JsonDeserializer;

/**
* @author Edward P. Legaspi
**/
public class XsdDateTimeConverter extends JsonDeserializer {

protected static Logger log = Logger.getLogger(XsdDateTimeConverter.class);

public static Date unmarshal(String dateTime) {
return DatatypeConverter.parseDate(dateTime).getTime();
}

public static String marshalDate(Date date) {
final GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(date);
return DatatypeConverter.printDate(calendar);
}

public static String marshalDateTime(Date dateTime) {
final GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(dateTime);
return DatatypeConverter.printDateTime(calendar);
}

@Override
public Date deserialize(JsonParser jp, DeserializationContext ctxt)
throws IOException, JsonProcessingException {
// format: 2014-04-08T07:08:48.1344874Z
String date = jp.getText();
if (date == null || date.length() != 28) {
log.debug("Null or invalid date=" + date);
return null;
}

// remove extra 4 milliseconds
date = date.substring(0, date.length() - 5)
+ date.charAt(date.length() - 1);

SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX");
try {
return sf.parse(date);
} catch (ParseException e) {
log.error("Error parsing date=" + date);
return null;
}
}
}

Well you can disregard the first 3 methods as it really not use. The most important part is in the deserialize method. It removes the last 4 millisecond characters so java can understand and parse it to a Date object. But how will the mapper know about this converter, of course you have to tell it :-)
ObjectMapper mapper = new ObjectMapper();
SimpleModule module = new SimpleModule("czetsuya", Version.unknownVersion());
module.addDeserializer(Date.class, new XsdDateTimeConverter());
mapper.registerModule(module);

And that's it when you call the reader from the mapper it should now parse the correct value of date string.

References:
http://stackoverflow.com/questions/6553051/setting-up-json-custom-deserializer
http://stackoverflow.com/questions/5106987/jax-ws-and-joda-time
http://www.baeldung.com/jackson-deserialization
http://stackoverflow.com/questions/21706415/jackson-objectmapper-using-custom-serializers-and-deserializers
http://blog.palominolabs.com/2012/06/05/writing-a-custom-jackson-serializer-and-deserializer/