That's right, we've got a new blog.
Unfortunately it looks like it's going to be tough to export all of our old blog posts into the new system. I don't know of a way that would transfer the posts and comments other than manually doing it (which would be ridiculous. I mean, that's what we have computers for!). The only thing I can think of would be to use this blog's RSS feed to retrieve all of the posts with their formatting (hopefully), and then I still don't know how to import those with the correct date into the new system.
Any ideas?
Oh yeah, this is also the last post for this blog, all new ones will be at the www.wombatstorm.com/blog page. Enjoy.
Monday, November 24, 2008
Monday, November 17, 2008
Java Generics and Variable Return Types
Back when I first started programming in Java, they didn't even have Generics. It was a simpler time. Admittedly, I was a freshmen in college just starting to learning Java (and programming for that matter) when Java 1.5 was released, so I really didn't understand what all the hullabaloo was about. I probably thought something along the lines of "Sweet! Now I don't have to cast when I use Vectors!"
Unfortunately my knowledge of Generics is still lacking, but I'm learning. Slowly.
Today I ran into a new problem: I wanted to a function to return a Vector of objects, but the type of object would change. So the usual solution of:
fails because I don't want to have to instantiate this particular class every time I want to call that function. I searched for a long time, and could see no way to define the return type of a function when it is called. If you know how, please let me know, because it seems like it would be useful at least in this one case.
In the end I had to settle for creating a generic inner class that the function could instantiate, and then writing a function for each type that I wanted. Not ideal, but the interesting code is not duplicated as it resides in the inner class. This solution also avoids the casting fest that would occur if I just decided to have one function that returned a Vector of Objects.
On a side note, during some "research" on Generics I happened across Whitespace, a programming language which only uses, you guessed it, whitespace. All non-whitespace characters are ignored.
Unfortunately my knowledge of Generics is still lacking, but I'm learning. Slowly.
Today I ran into a new problem: I wanted to a function to return a Vector of objects, but the type of object would change. So the usual solution of:
public MyClass< G > {
public Vector< G > myAwesomeFunction() {...
fails because I don't want to have to instantiate this particular class every time I want to call that function. I searched for a long time, and could see no way to define the return type of a function when it is called. If you know how, please let me know, because it seems like it would be useful at least in this one case.
In the end I had to settle for creating a generic inner class that the function could instantiate, and then writing a function for each type that I wanted. Not ideal, but the interesting code is not duplicated as it resides in the inner class. This solution also avoids the casting fest that would occur if I just decided to have one function that returned a Vector of Objects.
On a side note, during some "research" on Generics I happened across Whitespace, a programming language which only uses, you guessed it, whitespace. All non-whitespace characters are ignored.
Wednesday, November 5, 2008
A bit of code.
This being a blog about computer science, I'm surprised that we have yet to post any actual code. Well, that's about to change:
I know, I know, not exactly awe inspiring. In fact, Something about this code just seems wrong. It's ugly, with way to many "ifs" in a row and way to many return statements. Not to mention that it only works for one particular case! I mean, what happens when I want a check the syntax of something more complicated (which would be just about anything). Well at least it's commented.
This method took about a minute to write, and despite it's apparent inelegance, I am rather happy with it. I would even go as far to say that it's a solid piece of code. I've run quite a few malformed statements through it and it handled them with no problems whatsoever (due to the handy scanner class), and it's easy to read. It only handles a very simple syntax, but that's all I need for now.
Right now I'm building a prototype of a program that will test out the ideas I presented in Stabilize This. Right now all I want it to do is read in a text file of rules and then execute them on a simple graph. I can then see if the algorithm (rules) stabilizes within a certain time frame.
The next step would be to generate random graphs and track how the algorithm performs on each one. Finally, I will create a program that generates, combines, and mutates the rules. Then I will be able to generate and test algorithms to my heart's desire.
Right now you are probably thinking, "But James, isn't using plain text as an intermediary data structure going to be far to slow to do any significant amount of testing?" Absolutely, which brings me back to my ugly little piece of code: once it has served it's purpose it will be discarded as quickly as it was written. For now it's handy to have so I can easily create test cases and visually check the output of and generator that I make.
James
/*
* Form: if n(x) then set y
*/
private boolean checkSyntax(String s) {
Scanner scan = new Scanner(s);
if (!scan.next().equalsIgnoreCase("if"))
return false;
if (!scan.next().equalsIgnoreCase("n"))
return false;
if (scan.nextInt() < 0)
return false;
if (!scan.next().equalsIgnoreCase("then"))
return false;
if (!scan.next().equalsIgnoreCase("set"))
return false;
if (scan.nextInt() < 0)
return false;
return true;
}
I know, I know, not exactly awe inspiring. In fact, Something about this code just seems wrong. It's ugly, with way to many "ifs" in a row and way to many return statements. Not to mention that it only works for one particular case! I mean, what happens when I want a check the syntax of something more complicated (which would be just about anything). Well at least it's commented.
This method took about a minute to write, and despite it's apparent inelegance, I am rather happy with it. I would even go as far to say that it's a solid piece of code. I've run quite a few malformed statements through it and it handled them with no problems whatsoever (due to the handy scanner class), and it's easy to read. It only handles a very simple syntax, but that's all I need for now.
Right now I'm building a prototype of a program that will test out the ideas I presented in Stabilize This. Right now all I want it to do is read in a text file of rules and then execute them on a simple graph. I can then see if the algorithm (rules) stabilizes within a certain time frame.
The next step would be to generate random graphs and track how the algorithm performs on each one. Finally, I will create a program that generates, combines, and mutates the rules. Then I will be able to generate and test algorithms to my heart's desire.
Right now you are probably thinking, "But James, isn't using plain text as an intermediary data structure going to be far to slow to do any significant amount of testing?" Absolutely, which brings me back to my ugly little piece of code: once it has served it's purpose it will be discarded as quickly as it was written. For now it's handy to have so I can easily create test cases and visually check the output of and generator that I make.
James
Subscribe to:
Posts (Atom)