Before Java 1.5, I never really complained about the lack of enum keyword. Sure the old enum via class pattern was a bit verbose at first (N.B.: Java 1.5 enums can also be verbose once you start adding methods to them). But more importantly, you would often use the table lookup pattern in combination.
The problem with Java 1.5 enum is that it is not Object-Oriented. You can't extend an enum, you can't add an element in an existing enum. Many will say "but that's what enum is for, a static list of things". In my experience, the list of things often changes with time, or needs to be extended at one point. Furthermore, most people (including me when I am very lazy) end up writing switch statements on enum values. Enum promotes bad programming practices.
Think twice about using enum, this is often not what you want.
I tried Scala a few years ago. There are several good ideas in it, but I found the language to be a bit too complicated to master. But I recently stubbled upon a paper on Scala generics that might change my mind about using Scala.
Scala Generics used to work in a similar way as Java Generics: via type erasure. One main reason is compatibility with Java, another is that C++ like templates make the code base blow up. Scala Generics offered some additional behavior (the variance/covariance notion). C++ templates, however, have some very interesting aspects: one is that everything is done at compile time, the other is performance. If the generics are involved in any kind of computation intensive task, all the Java type conversion will create a significant overhead.
Now Scala has @specialized (since Scala 2.8). Annotating a generic type with @specialized will generate code. One has the choice to accept the performance penalty or to get all the performance but accept the code blow up. I think this is very useful.
If you read the paper you will see that the performance implications of this are not always small.
UPDATE: I thank the readers for pointing that this work only with primitive types to avoid autoboxing. It is still valuable but less than I first thought.
The MIT has a downloadable book on basic mathematics: Street Fighting Mathematics. I liked the part focused on the geometrical approach. It reminded me of the early greek mathematics.
Overall it does look like a very American approach to Maths: answering a multiple choices questions test by elimination. But it is still an interesting book.
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.
Yes, I wrote an applet. I know it is very 1990s but, amazingly, it still does the job quite well. Ok, next time I should really use Flash to do this.
The Applet simulates Diffusion Limited Aggregation as described in Chaos And Fractals from Peitgen, Juergens, and Saupe. It represents ions randomly wandering around (in a Brownian motion) until they are caught by an attractive force in electrochemical deposition experiment. This kind of phenomenon occurs at all scales, for example it happens in the distribution of galaxies. You can play around with the applet at http://31416.appspot.com/dla.vm
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.
In my previous post, I suggest that keeping a double[] performs better than keeping a double[][] if you do matrix multiplications and other operations.
This is actually not true. I benchmarked 3 libraries, Colt (uses double[]), Apache Commons Math (uses double[][]) and Jama (uses double[][] cleverly). At first it looks like Jama has a similar performance as Colt (they avoid [][] slow access by a clever algorithm). But once hotspot hits, the difference is crazy and Jama becomes the fastest (Far ahead).
JDK 1.6.0 Linux 1000x1000 matrix multiplication on Intel Q6600
loop index
Colt
Commons Math
Jama
1
11.880748
24.455125
9.828977
2
11.874975
24.265102
9.848916
3
9.772616
14.374153
9.826572
4
9.759679
14.368105
2.655915
5
9.799622
15.238928
2.649129
6
9.780556
14.741863
2.668104
7
9.72831
15.509909
2.646811
8
9.79838
15.724348
2.646069
9
9.726143
15.988762
2.646052
10
9.784505
15.121782
2.644572
We don't include matrix construction time, and fetching the result. Only the multiplication is taken into account.
The difference is less pronounced on smaller matrices, but still there. Jama looks very good in this simple test case. In more real scenarios, the difference is not so obvious. For example Commons Math SVD is faster than Jama one.
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.
We ran into an interesting issue with TimeZone and Dates. If you print the same date on different JVMs, it might show a different printed date.
The reason behind this is the daylight saving time conventions. An old JVM won't necessarily have the same daylight saving time for a given TimeZone than a latest JVM, and therefore will interpret the date differently.
Here is the output of a very simple program on 2 different JVMs. The number is the long number used to represent the date. I only use SimpleDateFormat with different TimeZone:
JVM 1.5.0_12 loading date=Sat Jul 18 06:59:36 CEST 2009, number=1247893176505 using formatter in EST: 7/17/09 11:59 PM using formatter in Asia/Singapore: 7/18/09 12:59 PM
JVM 1.5.0_20 loading date=Sat Jul 18 06:59:36 CEST 2009, number=1247893176505 using formatter in EST: 7/18/09 12:59 AM using formatter in Asia/Singapore: 7/18/09 12:59 PM
The source code:
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(); } }
What does this mean? This means that if you entered in a GUI in the first JVM a particular date & time using EST time zone. This will change when you read back in the second JVM. This suggests that if you want to keep the same dates, you are better off saving in UTC where daylight saving time is not used and trick DateFormat. But I have to say this looks quite ugly.
While trying to price a simple knock down and out barrier option, I encountered several difficulties I did not expect with the implicit finite differences method. The explicit method has less issues with barrier options pricing. I will show here what the tricky parts are and why explicit seems simpler in this case.
The full article is here (pdf) or here (html) (the later is not very well formatted).
