Groovy Science Expression Evaluation

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.

Groovy Science Expression Validation (Part 2)

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 ] );

The 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.”

Groovy Science Expression Validation (Part 1)

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 TestScience.testBasicAlgebraRepresentation().

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.

Grooving Pains

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.

Groovy Science, Revision 2

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.

Groovy Science Begins

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.