In short: Is Groovy Science dead? Yes and no. Yes, its author (me) is somewhat distracted with other things and has left the project to atrophy. On the other hand, no, its author (me) still has strong opinions about what it is and where it can go, and will probably pick it up again eventually if no one else does.
Well, I went back to school, and I left Groovy Science in a pretty unuseful state. I only got about halfway through the tutorials I was planning, I never set up a way to build a .jar file, and I didn’t even end up choosing a license. To trump that, I think I was going about it the wrong way from the start.
The premise was to make a common, easy-to-transform format for symbolic expressions, which could be used to help glue and wrap (groovify?) existing Java libraries. What I failed to notice was that Groovy already has a standard format for symbolic expressions: Objects.
Groovy Science isn’t what has my attention nowadays, but I’ve still been doing some thinking about it in my spare time, and I’d like to see it redefine itself in a few directions:
So, up to this point, there have been ways to create expressions and ways to filter out the incorrect ones, but in the past week, I’ve implemented a couple of ways to actually do things with them. I just finished talking about
CumulativeExpressionValidator, so now I present to you
CumulativeExpressionEvaluator. As with
CumulativeExpressionValidator, I’m not so sure that the interface is very good, but I’ll show you what I have.
Finally! Instead of writing this entry a week ago like I said I would, I kept pushing it aside in favor of pushing ahead on the project.
So, what kinds of things can
CumulativeExpressionValidator do? Well, the goal was to be able to declare an allowed
SymbolicExpression operator-argument combination in a way similar to declaring a function. In other words, my goal was to let people do something like this:
numberContext.allowAlso( plusOp, [ numberContext, numberContext ] );
numberContext expression validator presumably asks “Does the expression ultimately result in a number?” and this statement should modify that validator to also think, “If it’s ultimately adding two numbers, then yes, it does ultimately result in a number.”
I just finished submitting a whole bunch of changes to
CumulativeExpressionValidator that make it a lot easier to make a validator for
SymbolicExpressions. It’s at the point where I’m pretty sure I’m done focusing on constructing
SymbolicExpressions and I’m ready to focus on actually manipulating them. Further improvement on the construction aspect is of course possible and desired, but at this point, an example of the way I expect people to represent and validate algebraic expressions is available as
Another thing I should mention, for anybody who wants to build the code, is that I had trouble starting a new project in Eclipse based on the code in the repository. Once the project successfully builds once, it seems to be fine from then on, but I think my relative inexperience with IDEs and Eclipse made it so that I had particular trouble just figuring out how to get the project to build that first time. Anyway, whether or not there is some problem with the project structure, I can assure you that the Java and Groovy code itself is ready to compile.
I’ll update with some more detailed comments after I get some sleep.
I’m having some trouble moving ahead with Groovy Science, but ironically it’s because I can do too much.
I’ve always been a fan of Lisp despite the fact that I can’t get past the syntax to actually code anything. When I first saw Groovy, one of the many reasons I liked it was that it seemed to be a great step on the learning curve from Java to Lisp. What I didn’t realize was how deep of a step it was. Now that I’ve used Groovy for a while, I’ve started using it to prototype all of my ideas, as expected, but it turns out that it’s so easy to make these prototypes that I’m not sure exactly what work I’m saving Groovy programmers by writing a library. On the contrary, I’m starting to think the extra work of studying a library API might hinder people who want to do tasks as simple as this.
Well, I can sort of answer my own question: A library like the Java Collections Framework doesn’t solve a problem that is particularly difficult to get around on a case-by-case basis. It solves the frustrating task of making the same “easy” abstractions over and over again and coercing them to work with each other. This library is similar; treating something as a symbolic expression is already easy to do in Groovy, and that’s exactly why it can become a common metaphor, come up again and again, and eventually demand its own library.
Much of what I’ve been planning to contribute by Monday has been in the form of a Groovy prototype. I’m not sure exactly where to start translating that into actual library code, and that’s why I haven’t been submitting it. Whenever I figure out where to put it, it’ll start making its way into the library, I think.
I guess I’m still getting the hang of a few things here; my second contribution to Groovy Science takes most of what I did last time and tosses it out, all while making several major changes that could probably have been contributed individually. It seems to have taken me at least two days per revision thus far, and I think I should be shooting for about .7 days per revision. Maybe it’s just the fact that this is a brand new project….
Anyway, here are the changes. In case you’d like to see some examples, the unit tests in the TestScience class are probably pretty illustrative. Continue reading
Hello, world! My name’s Ross Angle (in case you need to know that). I just finished setting up the About page, which explains what I intend to do with this blog. Now I intend to do a couple of specific things.
First off, I intend to tell you what I’m doing, why I’m doing it, and how I expect to go about doing it.
Groovy is a JVM-targeted, Java-compatible, Java-like programming language that supports, among other things, closures and operator overloading. That makes it a much more comfortable language for manipulating symbolic expressions. Developers of Java-only scientific libraries don’t have the luxury of that kind of syntactic sugar when they design their libraries, so many of those libraries’ interfaces could theoretically be overhauled for the Groovy programmer in order to take advantage of convenient first-class symbolic expressions. That said, certain Java libraries do trudge through the syntax and provide symbolic expression classes of their own. I plan to make a symbolic expression implementation supported by tools that make it easier for Groovy programmers to adapt it for use with new Java libraries as they come along. Right now, the project is called Groovy Science, but it might be better known at this point as Groovy Scientific Module, based on the name of my application. Continue reading