In a node about partially committed transactions, Larry has this to say:
Transactions are not just something that database programmers have to worry about. I think training in transactional thinking tends to fall through the paradigmatic cracks because transactions can't be classified as functions or events or objects. If anything, a transaction is most closely related to the logic programming paradigm, which is undertaught. A transaction can be viewed as a sort of hypothesis that can either be proven or disproven. A partially proven hypothesis is of little use.
This gives me hope that logic programming will be supported in Perl 6. I've seen many mentions of that though no practical examples. I confess that if I have seen practical examples, I've yet to recognize them.
Last night, I did a bit of benchmarking of my code. I used this maze solving code. A query which WProlog solved in .8 seconds (solve(p(8,8),L)) took about 4 times as long in AI::Prolog, despite my code being almost a straight port (I say "almost" because some Java constructs don't translate well into perl.) However, the killer was solve(p(2,2),L). That code has over 84 million unifications and took 131 seconds for WProlog to solve. I stopped the Perl version after 45 minutes. It still hadn't solved it.
I assume this means there is a bug in AI::Prolog. I'll find it, but that was disappointing (I may not have much time over the next week, though, so patches or advice are welcome :). However, there is an upside. First, the memory usage didn't increase, so I wasn't wasting any more memory than WProlog. This is very important as the code is rather memory intensive. More importantly, I've done no optimizations. I won't do anything until I get math implemented, though. It's very important that the basic features get covered. Once they're in, extending it is easy (well, relatively speaking.)
As for optimization, I need to do profiling to know what to target first. For now, though, I'm using hashes where I should use arrays and, curiously, I've discovered that there is no need for the actual code to be OO. I'll leave an OO interface as that solves certain problems, but the original code used no inheritance and the only polymorphism was via multi-method dispatch, something Perl doesn't support anyway. Thus, if internally I skip the OO sugar and convert most (not all) hashes to arrays I'll be in a fantastic position to port the core to C. Now to find a good C hashing algorithm.
Re:Have you heard of...
Ovid on 2005-02-01T06:01:27
Thank you. That might be just what I am looking for.
As somone who tried to do only barely non-trivial arithmetic in a Prolog setting once, I am not surprised that WProlog doesn't feel the need of it. Peano axiom arithmetic would have worked better!
The maze program's suc/2 predicate provides equivalent to Peano axioms. Interesting, the wall/1 predicate defines a wall around two sides of a node, toward the lower numbers?
It's unclear to me why
would run long, but I'm assmunig its because it depth-first searches and has to backtrack fromsolve(p(2,2), L)
. Good luck tracking down the (1,1) (2,2) path.p(1,1)->p(1,8)->p(8,8)
Re:Re Prolog Arithmetic
bart on 2005-02-04T20:29:30
Seems like you've done it again! I think you were looking for this post.What on earth are you using to post?
Mis-Direction redux
n1vux on 2005-02-07T03:58:55
Weird, just using a web-browser, you'd think it would be fool proof!Re:Re Prolog Arithmetic (& Monsieur Wall)
n1vux on 2005-02-07T04:04:44
Nope, this is the one I wanted to comment - see the paragraph on the Benchmarking with the Maze predicates.Bill
