Thursday, August 2, 2012
I'm afraid I can't do that, Dave.
This blog is dead. But in case there is any residual traffic, check out our new blog, which probably will never go dead!
http://lookingforprogrammers.blogspot.com
Monday, November 24, 2008
We're moving.
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.
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 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
Wednesday, October 29, 2008
It's time to move on.
To a different website. Haha, did you see how I wrote an ambiguous title to trick you into reading the next sentence? Quite clever of me.
But as I was saying, I think that it's time to start looking for a new host. We need a site that can host files, and preferably one that will also host a repository for source control. Plus, it's about time we claim www.wombatstorm.com before someone else does.
But as I was saying, I think that it's time to start looking for a new host. We need a site that can host files, and preferably one that will also host a repository for source control. Plus, it's about time we claim www.wombatstorm.com before someone else does.
Monday, October 27, 2008
Stabilize This!
Matt brought up some good points in his post; we should be only posting about interesting and unique things. I look forward to his future posts, even if less regular.
This past week I have started a small project, inspired by a talk given by Alan Jamieson of St. Mary's College of Maryland on self-stabilizing algorithms for graphs. Hopefully he will post an abstract of his talk soon, since I'm sure that it will explain the subject much better than I am about to.
One of the most simple example is the toddlers and cookies example: each node of the graph can either be a plate of cookies or a toddler. For a toddler to be happy, it must be next to at least on plate of cookies (connected by a vertex). Giving a random graph with a random configuration of cookies and toddlers, write a set of rules that will place toddlers and cookies in such a way that all toddlers are happy (and thus stop their incessant crying).
The rules are as simple as "if a toddler is not next to any cookies, replace that toddler with cookies." The rules may become more complicated if you would like to find a set of rules that always result in happy toddlers with the least amount of cookies. The important part is that the rules are all simple "if...then" statements.
It occurred to me that one could easily generate these rules and then a bunch of graphs to test them out on. It would then be a simple matter to find the best set of rules. For a simple example like toddlers and cookies, one could just test every possible combination of rules. For a more complicated problem this might be unfeasible as the possibilities grow quickly.
At this point, I would like to see if a genetic programming approach could lead to usable results. All the elements are there: easy to generate and modify programs (the rules) that are easy to evaluate (number of moves, is the final graph correct).
So that's what I'm doing now. This post is quite long enough as it is, so I'll save my progress so far for another night.
This past week I have started a small project, inspired by a talk given by Alan Jamieson of St. Mary's College of Maryland on self-stabilizing algorithms for graphs. Hopefully he will post an abstract of his talk soon, since I'm sure that it will explain the subject much better than I am about to.
One of the most simple example is the toddlers and cookies example: each node of the graph can either be a plate of cookies or a toddler. For a toddler to be happy, it must be next to at least on plate of cookies (connected by a vertex). Giving a random graph with a random configuration of cookies and toddlers, write a set of rules that will place toddlers and cookies in such a way that all toddlers are happy (and thus stop their incessant crying).
The rules are as simple as "if a toddler is not next to any cookies, replace that toddler with cookies." The rules may become more complicated if you would like to find a set of rules that always result in happy toddlers with the least amount of cookies. The important part is that the rules are all simple "if...then" statements.
It occurred to me that one could easily generate these rules and then a bunch of graphs to test them out on. It would then be a simple matter to find the best set of rules. For a simple example like toddlers and cookies, one could just test every possible combination of rules. For a more complicated problem this might be unfeasible as the possibilities grow quickly.
At this point, I would like to see if a genetic programming approach could lead to usable results. All the elements are there: easy to generate and modify programs (the rules) that are easy to evaluate (number of moves, is the final graph correct).
So that's what I'm doing now. This post is quite long enough as it is, so I'll save my progress so far for another night.
Friday, October 24, 2008
Meh
So I blatantly missed my Wednesday post, sorry about that folks. I think that this blog is a good exercise for myself if I actively have something interesting to talk about: I am working on a project, doing research...and not just repeating plenty of things that could be read elsewhere.
Since I am not able to really talk about my work, I feel that I don't have anything worthwhile to contribute to the blog right now, so I am going to rescinde my promise of posting every Wednesday.
I will post when I have something worthy, and interesting, for our fair readers to read. So, probably once I have the energy to do some of my own work outside of the office, you will hear from me more often.
-Matt
Since I am not able to really talk about my work, I feel that I don't have anything worthwhile to contribute to the blog right now, so I am going to rescinde my promise of posting every Wednesday.
I will post when I have something worthy, and interesting, for our fair readers to read. So, probably once I have the energy to do some of my own work outside of the office, you will hear from me more often.
-Matt
Subscribe to:
Posts (Atom)