Bye Bye Firefox

I have been a long user of Firefox, mostly thanks to the adblock extension. But recently, Firefox decided to change the way arrows work on the web pages, they don’t make the page scroll anymore. Meanwhile Chrome has now a good adblock plugin (that filters ads on load, not after load like it use to be) and is really much much faster than Firefox. So there is no more reason not to use it.

Hello Chrome, bye bye Firefox. Google has won the web browsers war.

Diffusion Limited Aggregation Applet

Java & 3D Surface

I have been looking all around the web for a Java library that can draw a simple 3D surface. And I did not find any. Most charting library, including the well known JFreeChart, can only draw 2D charts.

I am quite shocked that something that has been in Excel for 15 years is still not available in Java. And it’s not easy to make your own.

double[][] Is Fine

The Pain of Java Matrix Libraries

Looking for a good Java Matrix (and actually also math) library, I was a bit surprised to find out there does not seem to be any really serious one still maintained.

Sure, there is Apache Commons Math, but it is still changing a lot, and it is not very performance optimized yet, while it has been active for several years already. There is also Java3D, it does Matrix through GMatrix, but not much linear algebra and if you look at their implementation, it is very basic, not performance oriented.

The other candidates seem to be 1-man projects that can disappear any other day (some of them look quite good like ojalgo, most of them are not interesting). Then you also have the serious but not maintained anymore Cern Colt library.

Compared to C/C++, the Java world is worrying if you want to do maths.

In those libraries, a dense matrix of double can be implemented two ways:

• by maintaining internally a double[][]. Usually those libraries allow for not copying the array, so it can be neat if your interfaces have this kind of arrays.
• by maintaining internally a double[]. The reason is for performance, but then each time you build a matrix from a double[][], an expensive copy will happen. So you need to use the Matrix object in your interfaces instead of double[][].

This is a pain because you can be very quickly stuck in one or the other Matrix library. A “solution” is to have your own interface, but that is a pain to write. There is UJMP, but it can hide some important methods (like transpose and multiply in one go from Colt or the ability to reuse an existing matrix in various operations to avoid allocating new memory), it is a students project (like parallel colt), but if it was a standard, it could be much more interesting.

In summary it does really look like scientific people, universities don’t use Java for computation otherwise Colt surely would have been maintained.

Java Calendar Is Broken On JVM Upgrade

public class DateBug {       
   
    private static String FILE_NAME = "datebug.txt";
   
    public static void load() throws IOException {
        FileReader fr = new FileReader(FILE_NAME);
        BufferedReader br = new BufferedReader(fr);
        String l = br.readLine();
        br.close();
        long time = new Long(l);
        Date d = new Date(time);
        System.out.println("loading date="+d+", number="+d.getTime());
        SimpleDateFormat formatter = new SimpleDateFormat();
        formatter.setTimeZone(TimeZone.getTimeZone("EST"));
        System.out.println("using formatter in EST: "+formatter.format(d));
        formatter.setTimeZone(TimeZone.getTimeZone("Asia/Singapore"));
        System.out.println("using formatter in Asia/Singapore: "+formatter.format(d));
    }
   
    public static void saveNew() throws IOException {
        Calendar c = Calendar.getInstance(TimeZone.getTimeZone("EST"));
        c.set(2009, 06, 17, 23, 59);
        Date d = c.getTime();
        System.out.println("saving date="+d+", number="+d.getTime());
        SimpleDateFormat formatter = new SimpleDateFormat();
        formatter.setTimeZone(TimeZone.getTimeZone("EST"));
        System.out.println("using formatter in EST: "+formatter.format(d));
        formatter.setTimeZone(TimeZone.getTimeZone("Asia/Singapore"));
        System.out.println("using formatter in Asia/Singapore: "+formatter.format(d));
       
        FileWriter fw = new FileWriter(FILE_NAME);
        PrintWriter pw = new PrintWriter(fw);
        pw.println(d.getTime());
        pw.close();
    }
   
    public static void main(String[] args) throws IOException {
        System.out.println("JVM "+System.getProperty("java.version"));
        if (args.length == 1) {
            if (args[0].equals("save")) {
                saveNew();
            }
        } else {
            load();
        }
    }

Implicit Finite Differences Method For Pricing Barrier Option

Pulseaudio Nightmares - Pure ALSA to the Rescue

 
pcm.amix {
   type dmix
   ipc_key 50557
   slave {
       pcm "hw:0,1"
       period_time 0
       period_size 1024
       buffer_size 8192
   }
   bindings {
       0 0
       1 1
   }
}

pcm.softvol {
    type            softvol
    slave {
        pcm         "amix"      #redirect the output to dmix (instead of "hw:0,0")
    }
    control {
        name        "PCM"       #override the PCM slider to set the softvol volume level globally
        card        0
    }
}


pcm.!default {
    type            plug
    slave.pcm       "softvol"   #make use of softvol
}

Java int Overflow Behavior

A coworker recently asked me if there was a guaranteed behavior in the case of int overflow. He gave the specific example on:

can we rely that int x = Integer.MAX_VALUE + 1 is the same for every JVM on any platform?

I thought the answer would be easy to find in the Java specifications document. But I was wrong. It is not clearly defined.

I found a trick that suggests this behavior is indeed standard and will stay the same, it is related to type casting. Java guarantees that the cast of a long just truncates the long to int precision. Therefore if

long l = Integer.MAX_VALUE;
l = l +1;
x = (int)l;

x has a guaranteed value. http://java.sun.com/docs/books/jls/third_edition/html/conversions.html paragraph 5.1.3.

Static Fields and Inheritance

class Toto extends TotoParent{

 final static Toto a = new Toto ("a");

 public Toto(String a){
  super(a);
 }
}

import java.util.ArrayList;
import java.util.List;

public abstract class TotoParent {

 static List list = new ArrayList();
 
 public TotoParent(String a) {
  list.add(a);
 }

 protected static List get() {
  return list;
  
 }
}

import org.junit.Test;
import static org.junit.Assert.*;

public class TotoTest {

 @Test
 public void testGet(){
  assertEquals(1, Toto.get().size());
 }
}