breadth-first, graph traversal, DLA, diffusion-limited aggregation, IDE, development environment, J7
Location::Heartland, Empire State Building, NYC
Agenda for NYCJUG of 20091110
1. Beginner's regatta: simple breadth-first example: see "Breadth-first search.doc". "stackoverflow.com" and other questions sites: worth visiting? 2. Show-and-tell: further adventures with diffusion-limited aggregation - see "Introduction to Phase Two of DLA Development.doc" and "Building a Close Neighborhood.doc". 3. Advanced topics: what's new with the upcoming J IDE? See "A J IDE.doc". What do we want from an IDE? 4. Learning, teaching and promoting J: Matlab libraries: what's needed to dent this advantage? What's the advantage of Meetup?
We had a good turn-out though our new status as a Meetup appeared to pay no dividends.
We discussed the problem (a "breadth-first" graph traversal) and solution shown here.
It's debatable about how useful this sort of answer is but there's some hope of arousing interest in such a short, easy-to-write solution. As I mentioned in this essay, it took me about fifteen minutes to code everything shown. It's interesting to note that none of the other respondents attempted to supply any actual code, for the obvious reason that it would require a substantial amount of time to get something working in a more conventional language. Also, the problem is vague on the purpose of the traversal, so it's not clear what the numbers in the graph mean though these sorts of problems are often ones of minimizing edge weights.
Is the objective to minimize the path? Are the node amounts subtracted from the edge totals? "G1" and "G2" might be "Goal 1" and "Goal 2" and "S" is probably "Start".
Dan tried to mention that this problem could be solved easily by transitive closure but I re-iterated my irrational, personal ban on learning anything about that.
The nice thing about the solution is how the data structure bears so much of the weight: it removes complexity from a series of changing values in an algorithm and keeps it in a static, easily verifiable array.
Is the code understandable, or at least somewhat, by someone who doesn't known J? Would it motivate someone to learn it?
Some of us agreed that often people don't really attempt to read code but rely on a description of it, even for more conventional languages.
Show and Tell
We discussed some work I've been doing on some existing code on the J wiki for implementing a sort of fractal growth technique called "diffusion-limited aggregation" (DLA). It may be useful to introduce J novices to the different way of thinking inherent in the language by showing how a conventional approach - as shown by the original code - might be changed to make it more J-like. Some of this initial change is shown here.
The details of further developing DLA are shown in more detail here.
There is an interesting contrast between the approach in this problem versus the previous one: here we turn a simple matrix into a list of points whereas in the former, we turn a series of edges into a matrix.
This solution also seems very extravagant of memory and CPU in comparison to a more conventional one. However, it runs in a reasonable time and compares well to the starting solution.
This essay moves from a more conventional to a more J-like solution and introduces notions of timing as we go, benchmarking, and testing along the way. Could sparse arrays help here? They don't seem well-developed in J because they aren't much used, hence don't work well, hence aren't further developed because not many people use them.
Upcoming J IDE: how many use the existing one? How does JOD tie in? Maybe we don't use one because of the size of the problems with which we usually work? We're considering this topic in anticipation of Chris Burke's visit to our meeting next month. We all have different needs and expectations of our development environments so it will be interesting to see how the new release might address these.
One improvement: why can't we download the whole J forum, maybe with package manager, on which to perform our own searches? Finding things in J is a continually recurring problem. This is one reason we each need to continue to contribute essays solving problems - you never know what someone might look for and what they might find useful in an exposition. It's impossible to classify everything.
Learning and teaching J
Maybe a project to do what Quantlib (an open source C++ library for quantitative finance) attempts? There was a recent posting on a LinkedIn group asking the members about their use of this library. A number of people commented on the unnecessary complexity of its design. One of its drawbacks is its insistence on object-orientation when a functional paradigm is probably more useful in this context.
Also, if you've ever dealt with a body of compilable code from the 'net, you'll know that it often requires a fair amount of effort to get it into a usable state. The lightness of J would seem a much-needed antidote to this unnecessary complexity.
There will be an APL (Array Programming Languages) conference in Berlin next Autumn. The APL2010 conference has issued a call for papers. This conference theme is "APL : LPA :: Array Programming Languages : Learn Parallel Applications".
Scan of Meeting Notes