I am currently using PyKnow (https://github.com/buguroo/pyknow/) as a rules engine for dialog management (to drive topic stack frame selection). It's just a prototype so far and I have barely scratched the surface of expert systems, GOFAI and logic programming in general.
It is based on CLIPS [1] which is a knowledge-oriented expert systems thing developed at NASA. It allows encoding logic as "gates" that solve for constraints with left-hand-side facts triggering right-hand-side consequences. I like to tell the business people it's like "IFTTT for X".
Can someone with experience contrast this kind of thing with real logic programming? Is it just the level of formality and provability? Are there many logics like we have in philosophy (symbolic, predicate etc.) that are used in programming?
Looking at the source, it seems to be part of the title. Chrome (and Chromium based browsers don't appear to display it.
It was probably just a bad copy paste. I have seen invisible characters used intentionally as markers or invisible water marks but I doubt that's happening here.
It's better to send an email to the mods hn@ycombinator.com They usually remove the strange character as soon as they get the email. (They are probably sleeping now.)
I've recently completed my PhD in the automated design/generation of constrained ship hull form geometry. This is a method that originated in the 90s for generating the basic geometry of a ship from "scratch" - well actually from lists of "form parameters" which are really constraints. The method uses nonlinear programming to solve for B-splines (other representations could be used) which minimize some functional and satisfy constraints.
Ship hull shapes can get pretty complicated. Now the trick is to specify, ahead of time, constraints which are consistent with each other, so that, in the first place, the nonlinear solvers don't waste time on bad designs, and really, we'd like to be able to search the design space without such waste.
The way I found to address this issue was to view the design space as interval valued. (By the way the design space is usually viewed as the space of all possible combinations of real valued constraints). With intervals we could reason about the design space using our constraints, but we need some kind of solver to narrow down the answers. There is an enormous amount of interval and constraint solving literature here, of course.
First, being from a numerics background, I tried working only with the intervals themselves. Nonlinear interval solvers for constraint systems. Long story short, the global methods need local help to make progress when the domain contains singular points and other places where the numerics are not so nice, in real or floating point. Local methods are really simple - just invert a single constraint at a time, in the simplest case. The issue here is that you need to solve for each constraint variable in terms of all the others. This is relational constraint programming and is something that Will Byrd has stated that miniKanren is good for. (Will is co-author of miniKanren, and a really nice guy)
Now, the second trick is that we want to compose with any random constraint that the ship designer dreams up (within reason, and my personal time constraints ;). So I hacked out an interval valued version of "miniKanren" which lived within Python. (think reverse mode automatic differentiation facilitated by operator overloading to embed the math operations directly into numpy. Take that programming idea, and change it to compose a computational graph of constraints, instead of differentiation.)
In short, it worked as well as I'd hoped. The relational logic front end can "quickly enough" narrow the design space as new rules come in, and then even a random number generator can select feasible designs. (Hint hint, time to add more efficient design space learners.)
It's a long story, shortly told, but I'd claim there are applications in the engineering space.
This is great. Is any of it available? I've spent a lot of my winter break working on fitting splines to my hand-drawn chines and then make developable surfaces out of them for stitch and glue kayak building. I'm still in the hacky Jupyter notebook phase of the project but I'd love to see what you've produced.
Thanks a lot! It would be cool to have some of it get used! I've been trying to get all of it online. Right now there is not really anything coherent ready to put up yet - a smattering of Jupyter demos using/explaining aspects of the code. this keeps getting triaged for another day, and yet I keep seeing bezier and B-spline stuff get popular on here.
It's a huge swath of messy python with the first stuff dating back to 2012. I used Piegl and Tiller's book C++ converted to python for the underlying B-spline stuff. (needed to implement anyway in order to compute constraints and objectives for custom auto-diff solver...)
Then convert the spline control points into an overloaded automatic differentiation type for use in construction of the basic curve solver. That we at least have documented publicly in the journal of CAGD here: https://www.sciencedirect.com/science/article/abs/pii/S01678...
The stuff above made it easy to be really flexible about what constraints are used in any given curve. (Or surface, but I did not go there for direct optimization.)
Next comes... all the interval arithmetic and relational constraint logic to pare down the design space to only the feasible domain on the front end. It's going to take a while to clean up the code and tell the story better.
The trick for kayaks is that my professor had me focus on industrial applications. -Designing offshore supply vessels, that sort of thing.
I could work with you to try and re-tool a bit to see what we could get. I can't make promises though! I am swamped with a new baby and various other job related things at the moment.
Nevertheless it should be pretty easy to get started, since a kayak is a sort of generalized canoe, which is the first hull form anybody generates. The outstanding issue is that I've not yet worked on developable constraints!
(Actually I've been tooling up to bring some discrete differential geometry to bare on this) The issue here is that nonlinear B-spline surface optimization direct is expensive. See, e.g. https://www.cs.cmu.edu/~kmcrane/
Developable triangle meshes and other such papers. Cool stuff. Of course the shape representation is different.
There are the old directrix techniques as well.
I work a lot with nested BOMs (bill of materials) for products, and just looking at the examples here, I can think of several areas where adding this to some python data structures to deal with parents and children, would be more elegant than what we currently have. Might be useful enough to pull in as a dependency.
These kind of Prolog-like systems are actually not very hard to make using Python generators. I think it's a nice exercise to really understand the intricacies of Prolog! My own try is here: https://github.com/evertheylen/logicpy (not as extensive as kanren though)..
I think you maybe need to know quite a lot about both in order to have a good answer. If you want to learn a bit, the reasoned schemer is the best jumping off point imo.
This is maybe the best internet answer, by the author:
From the readme, this is based on miniKanren, so the name is a reference to that language. miniKanren itself has a Wikipedia page that also mentions the Japanese etymology of the name.
Logic languages like Prolog are usually based on relations (or "constraints"), which is likely where the name ultimately came from. As for why Japanese, I don't think there's going to be a particularly good answer to that question.
probably just because it’s fun to use foreign words as the name of things since you can have something sound like a name and not just a word but have a direct meaning or represent a concept.
also, weren’t (maybe it should be “aren’t”) the japanese heavy users of prolog?
> it’s fun to use foreign words as the name of things
Oh definitely! I wrote a FAT16 stack for an embedded system and called it "FutoiFS" (ha, ha) [1]. I think whimsy is a perfectly good reason. It sounded like the OP wanted a reason for choosing Japanese specifically, though, and I don't think such exists.
It is based on CLIPS [1] which is a knowledge-oriented expert systems thing developed at NASA. It allows encoding logic as "gates" that solve for constraints with left-hand-side facts triggering right-hand-side consequences. I like to tell the business people it's like "IFTTT for X".
Can someone with experience contrast this kind of thing with real logic programming? Is it just the level of formality and provability? Are there many logics like we have in philosophy (symbolic, predicate etc.) that are used in programming?
[1] http://clipsrules.sourceforge.net/documentation/v640/ug.pdf