Comments for CDA

Comment on Concurrent Hierarchical Reinforcement Learning & Lisp by aim

aim — Fri, 04 Dec 2009 02:14:37 +0000

Despite its age, Lisp isn't a stale language. It's continued to develop over the years, and has spun off several variants. If you're looking for a modern Lisp, you might try Clojure. It's a Lisp dialect that targets the JVM (which means ready access to Java libraries). It also adds a bunch of modern features like actor-based concurrency mechanisms and software transactional memory. Another alternative is PLT Scheme, which has become quite popular for teaching and programming language research.

Comment on pi: a pattern language by aim

aim — Sun, 01 Nov 2009 21:18:33 +0000

As Damien Guichard has pointed out, this seems like it's probably related to the pattern calculus work that's been going on at the University of Technology Sydney.

Comment on pi: a pattern language by aim

aim — Thu, 29 Oct 2009 05:20:26 +0000

Yep, it’s Unicode. From the project website: “A π-program is a sequence of instruction symbols (technically, sentences), each being a sequence of (Unicode) characters.”

One of the examples is:
// the pattern: declare_pattern ≔ "√" %W- ⇒ float ➞ square_root (number);

// the usage: if (n ∈ ℕ ∧ n ≥ 0) print (√n);

Comment on pi: a pattern language by Peter Raffensperger

Peter Raffensperger — Thu, 29 Oct 2009 03:58:39 +0000

It seems like that could work pretty well although it seems like it has a great potential for obfuscation (like C++ and pretty much everything that flexible).

Is the text of the code Unicode? That seems like an interesting idea just by itself.

Comment on SPARK Ada by aim

aim — Sun, 11 Oct 2009 06:25:53 +0000

The documentation I’ve been able to find so far is also fairly thin. It looks like there’s probably a lot more detail in “the SPARK book” – John Barnes’ “High Integrity Software” – which Praxis recommends anyone should read before tackling SPARK. Maybe I’ll see about ordering a copy for the library.

Comment on SPARK Ada by rwebb

rwebb — Sun, 11 Oct 2009 02:44:46 +0000

I read some of the tutorial on the SPARK website, but I don’t understand what sort of checks are guaranteed. What if I write “x = x + f()” where f returns one if some complex computation will halt and zero if it won’t halt. Or maybe my function, f, has some hideously complex logic but always returns one in the current implementation. How does SPARK know this? What if ‘f’ depends on a piece of hardware being attached. I wish they’d be clear about what the analysis does and doesn’t do.

Comment on Comparing Echo State Networks with Multiple Context by John H Andreae

John H Andreae — Mon, 05 Oct 2009 04:17:45 +0000

Thanks for the comments, Peter and Allan.
PP already evaluates predictions from contexts (nodes) in terms of the probabilities that the node will be followed by other nodes with reward, novelty or disapproval. So far, the templates that determine what event types can go into a context have been treated as inbuilt or innate. Thus, in my current implementation there will be up to 15000 nodes matching the requirements of a single template, before forgetting starts to throw away the least useful nodes. Also, when the nodes of two or more templates are predicting the same event type, a pre-determined priority structure gives one preference over another. Thus, if one template is a proper subset of another, then it is less powerful and must be given a lower priority. The new possibility of evaluating the templates as a whole could gradually take over control of the priority structure. I am not sure, Allan, whether the weights on the templates could be turned into probabilities on the predictions in any mathematically meaningful manner. At the moment, mathematical probability and expectation only applies within the network of nodes generated by a single template. Non-linearity should help, Peter, in choosing between predictions from the nodes of different templates, but I haven’t given much thought to that. Too confusing!
I must write up the details of these processes.

Comment on Comparing Echo State Networks with Multiple Context by aim

aim — Mon, 05 Oct 2009 00:44:39 +0000

Peter, it seems to me that PURR-PUSS is already (from what I’ve seen of it) quite nonlinear. An ESN takes real numbers as inputs, and produces predictions that are a (usually nonlinear) function of those inputs. The PURR-PUSS system appears to take abstract symbol sequences as inputs, and maps that sequence to a prediction. While you could force such a system to be linear — perhaps by mapping each abstract symbol to a number, and arranging the contexts such that the mappings they embody were linear with respect to the encodings — the PURR-PUSS template/context system isn’t constrained to linearity. Instead, it’s a tool for defining and learning quite general relations.

John, your idea of assigning weights to templates is intriguing. It seems as if what you would be doing in that case amounts to assigning probabilities to the predictions associated with different templates, and updating those probabilities in response to the success of failure of each new prediction. This does seem like quite a powerful idea.

Comment on Comparing Echo State Networks with Multiple Context by Peter Raffensperger

Peter Raffensperger — Sun, 04 Oct 2009 20:57:32 +0000

In ESNs, one of the powerful things (as far as I know) is the non-linearity. So you not only get exactly what you put in as an input, but various complicated functions of it as well.

Perhaps one could also define functions of PURR-PUSS contexts that would be analogous to non-linear functions of real numbers. I can’t immediately think of how you could take mix up the content of a context, but you could always shift its events forwards and backwards in time.

I’m just thinking aloud here, I suspect this idea has a low probability of being useful in its current form.

Comment on Erlang, Haskell, and some thoughts on robust software design by aim

aim — Wed, 30 Sep 2009 22:58:34 +0000

Hi Ulf! Good to see you posting here. I had much the same experience when I first encountered occam (which of course takes a similar approach to Erlang). Unfortunately, for some reason these ideas haven’t really become “mainstream” yet. But perhaps the growing awareness of the need for tools to deal with multicore systems will see the software development community move in the right direction.