| Subcribe via RSS

Tail Recursive Algorithms In Scala

September 18th, 2008 | 4 Comments | Posted in Computers, java, programming

< ![endif]–>After the NFJS conference this weekend I have been spending more and more time working in Scala and trying to learn the ins-and-outs of the language.  One of the neat things I came across was tail recursive algorithm optimization within the language itself.

When writing in a functional language like Scala you rely heavily on recursive algorithms to do your work, instead of iterative algorithms more present in OO languages like Java. This leads to an interesting problem with running functional languages within the JVM.

The Java Virtual Machine does not have support for tail-recursive algorithm optimizations.  What does that mean? Basically the JVM cannot spot when to optimize calls stacks for recursive algorithms. Well who cares right? If you’re writing in Java this issue doesn’t usually come up since most of us simply write our loops and are happy with the performance the JVM offers us.

However, when you are writing a lot of recursive algorithms you quickly start to see how tail-recursive algorithms help makes your code more efficient.

For those of you who don’t remember what a tail-recursive algorithm is, here is a short little explanation:

A Tail-recursive function is a function that ends in a recursive call to itself (effectively not building up any deferred operations). Tail recursive functions have the ability to re-use the same stack frame over and over and therefore are not bound by the number of available stack frames.  Many people have written the simple factorial function recursively, but many have noticed that if you pass it a value of N that is large enough you will see a dreaded Out of Memory exception.

The reason for this is due to the factorial functions deferred operation statement that comes at the end of the method. Let’s look at the simple factorial algorithm

1
2
3
4
5
6
7
//INPUT: n is an Integer such that n &gt;= 1
int fact(int n) {
   if (n == 1)
      return 1;
   else
      return n* fact(n-1);
}

H You can see that at then end of the algorithm we have a deferred operation of multiplying n with the next value computed from factorial, this goes on and on until we finally hit a factorial function that returns one, at which point the stack is popped and everything returns nicely. However we are now bound by the available stack frames in terms of computing n (Also by the max size of an int, but that’s beside the point).

In a tail-recursive algorithm you do not see this deferred execution, and therefore the same stack frame can be reused over and over again. Here is the same algorithm rewritten using a tail-recursive algorithm.

1
2
3
4
5
6
7
8
9
//INPUT: n is an Integer such that n &gt;= 1
int fact(int n) {
    return fact_support(n, 1);
}
 
int fact_support(int n, int acc) {
    if (n == 0) return acc;
    else return fact_support(n-1,acc*n);
}

As you can see there are no deferred operations in this example we have effectively gotten rid of having to use n number of stack frames. Each call to fact_support brings with it the current accumulated sum, and thus does not need to wait to “pop” the stack and rely on the stack pop to accumulate the sum of the factorials.

As you can see tail-recursive optimizations are very important to languages where recursion is relied on heavily. Without this type of optimization many of the recursive algorithms are now bound by the number of available stack frames.

So that can’t be so hard right? Why not just write all your algorithms to use tail-recursion? Well for one it’s not always possible to do this, but also it puts a lot of work in the hands of the developer. We have this beautiful thing called the JVM that should be able to spot cases where optimization can occur.

Unfortunately the JVM doesn’t know how to spot this optimization, therefore the Scala compiler must look at ways of optimizing your code. Even more unfortunate the Scala documentation explicitly states that you should not rely on the Scala compiler making this optimization.

It may optimize your code, but it may not as well, so really the only way to be sure is to write your algorithms guaranteeing that tail-recursion is being utilized from the get-go.

It would be really nice to see the JVM improved to allow for this type of optimization to be done in the Hotspot, and there has been talk about improving the JVM to support functional languages, but I guess time will only tell.

Tags: , , ,

No Fluff Just Stuff Boston 2008 Overall Review

September 16th, 2008 | No Comments | Posted in Computers, java, programming

I’ve spent my weekend in Boston at the local No Fluff Just Stuff conference and I figured I’d write a little summary of what I observed and learnt over the weekend.

To start this was my first conference that I’ve attended besides some small ones while in College and University, and I have to say that it was both exciting and disappointing.

Heading into the weekend I was very excited to hear Brian Goetz and Ted Neward give talks about cool things like Java Concurrency, The Java Memory Model, Hacking the JDK, Scala etc, and I expected most people at the conference to be of the same mind set.

I found through talking with many attendees that most people seemed to share a different set of values as to what was important to them. I found this to be very interesting as it really showed me the difference between people who are developing for the “Enterprise” or big business and people like me who develop more for a technology based company.

When I heard people talking about Groovy and Grails I couldn’t understand why anyone would be so interested in a language that performed as poorly as Groovy (Yes I know it’s been getting better but when you start from incredibly slow, and move to just being a little less incredibly slow I hardly see this as an improvement) I started to see that there really is a difference between the enterprise developer and the developer.

I think this was an amazing aspect of this conference is that it really opened my eyes to the other side of the coin, to the developers that work hard to create the applications that we use every single day from our Banks, Insurance companies etc and the different set of requirements that their applications have to deal with then what I’m used to.

I also have to say that after this weekend I am VERY VERY glad to be working where I am. Some of the horror stories I heard from people as to how they have to work, the lack of tools support that they face, and an overall management’s lack of letting things change made me cringe in pain and a few times I just wanted to give them a hug to tell them that it would all be OK (Yes sometimes it really was that bad like the guy who told me they were still using Java 1.4.2 because his boss thought if it works don’t fix it!)

So after sitting back over the weekend and getting over the initial culture shock that I faced meeting a lot of these developers, I have to say that this conference helped me in a way I never thought it would.

Sure I learnt all about the Java Memory Model, and how I can modify byte code on the fly with tools like BCEL, but more importantly I learnt what other developers have to go through on a daily basis and what it’s like to be an Enterprise developer in the real world.

All I have to say to that is, thank god I don’t have to deal with that shit every day.  Overall though I definitely would recommend this conference to someone working in the Enterprise world, I definitely got value out of it though with my talks with Brian and Ted and I have to say that if they weren’t there this show definitely would of been a wash for me.  So thanks Brian and Ted for really opening my mind and eyes to some cool new ways of doing things.

Tags: , , , , , ,

Picked up some new books

September 1st, 2008 | No Comments | Posted in Computers, General, Technology, java, programming

Last week I finished the book “Prelude to Foundations” by Isaac Asimov.  It was recommended to me by my boss, and I have to say it was one of the better books I have read in a while.  I usually try to switch up reading technical books with non-technical books, and since I haven’t read any new technical books I decided to head over to chapters and pickup some new books.

I have head great things about both Java Concurrency by Brian Goetz, and Effective Java 2nd Edition by Joshua Bloch.  The real problem with both these books is they are hard to find in store.  I happened to come across both of them at my local Chapters, and quickly snatched them up.

I have been reading Java Concurrency over the past couple of days and I have to say this is one of the best Java books I’ve read in a while.  Brian Goetz has a way of writing that really helps bring complex problems into perspective.

One of my initial gripes about this book was the lack of exercises at the end of the Chapters, however now that I’m a little ways into the book I’ve noticed that the examples chosen for each Chapter progress almost as a set of exercises in themselves.  Not to mention that Brian picks examples that relate well to the real world, instead of most of the silly easy examples found in other books I’ve read.

I would definitely recommend this book to anyone looking to delve into the world of Java Concurrency, or even someone looking to freshen up on the latest stuff available in JDK 1.5 in terms of threading.  This book has really helped me in my pet projects and in my day-to-day work so I would definitely recommend getting it and keeping it close by.

I’ve yet to really get into Effective Java, but the little bits I’ve read here and there have really shown me that this this book lives up to all the hype about it.  Joshua is a smart man, and this book definitely reflects his intelligence.  It is well organized and shows you things about Java that you never thought even existed.  I’m really excited to delve deaper into this one.

I’ll write a more thorough review once I’m finished with it.  Anyway until next time …

Tags: , , ,

Java String Comparisons

November 14th, 2007 | No Comments | Posted in Computers, Technology, java, programming

Today I thought I would take some time to outline basic String comparison in Java. To many newcomers using Java doing comparisons using String can be confusing. Take for example the following piece of code which compares two String literals and two String objects. To newcomers of the Java language the following is confusing. Let’s take some time to outline how this actually works, and what actually makes it confusing.

[sourcecode]
01 public class Test {
02   public static void main(String[] args) {
03     String a = “abc”;
04     String b = “abc”;
05     String c = new String(“abc”);
06     String d = new String(“abc”);
07     System.out.println((a==b);//true
08     System.out.println((c==d));//false
09   }
10 }

[/sourcecode]
First let’s look at the instructions used to generate a String literal in Java. It’s fairly straight forward for anyone who’s seen assembly before. We simply store the literal value using the instruction sets store command.

Instruction used to generate String literal
0: ldc #2; //String abc
2: astore_1

On the other hand there are many more instructions used to generate a String using the new operator. Since we are using the new operator we create a new reference to memory location, duplicate it, load the String literal and invoke a special init function on that new memory. In Java terms we are merely creating a new object and invoking that objects constructor with the parameter “abc”.

Instruction used to generate new String()
6: new #3; //class java/lang/String
9: dup
10: ldc #2; //String abc
12: invokespecial #4; //Method java/lang/String."<init>":(Ljava/lang/String;)V
15: astore_3

So the question still remains, why does a==b return true, and c==d return false? First let’s look at the == operator itself. The == operator works on String object references. If two String references point to the same object in memory, the comparison returns a true result. Otherwise, the comparison returns false, regardless of whether the text has the same character values.

The == operator does not compare actual char data. So we know now that the == operator is looking at comparing two object references, but how can a==b be true?

Well this comes down to the different way Java handles literals. The Java platform creates an internal pool for string literals and constants. String literals and constants that have the exact same char values and length will exist exactly once in the pool.

Subsequent comparisons of String literals and constants with the same char values will always be equal. So you see we could create a million String literals with the value “abc” but Java would only have reference in it’s internal pool to a String literal with value “abc” and length 3.

On the other hand c and d are not String literals they are String objects, and therefore are not created in the Java String literal and constant pool. These objects will each have it’s own reference in memory and therefore will have different values for their references.

Using the == operator to check whether their reference points to the same value will never be true since each occupies it’s own slot in memory.

If we wanted to compare the actual values stored within the String instead of their references, we would simply use the equals method or the compareTo method.

I hope this helps clarify some of the mystery behind how Java handles String and I hope I have helped increase your understanding of String comparisons in Java. Next time we’ll take a closer look at Natural Langauge text comparison in the Java language.