clojure code

[YKY (Yan King Yin, 甄景贤)]

Hi all,

Forward-chaining is ready...  but I'm not sure how to upload it to the repository.  I started using Leinengen the Clojure project manager, but it creates a complex directory structure for the project.  I'd rather the source files stay in one neat place.  Also, due to calling a combinatorics library, the code now has external dependencies.  Lein takes care of that automatically, but if not using it I don't know how the deps can be managed.

KY

[Russell Wallace]

When I was using Java, what I did about dependencies is, for each
library I used, I put the jar in the project lib/ directory (setting
the classpath accordingly in ant or whatever build system one uses
with Clojure) and checked it into version control, to make sure anyone
downloading the code could compile and run it with no other manual
steps, regardless of what happened to the upstream websites.

I should disclose that some people disagree with the above strategy,
and prefer to download dependencies at compile or install time from
their upstream websites, typically using maven (which supports this)
rather than ant.

[YKY (Yan King Yin, 甄景贤)]

I found out that with Java, you cannot change the directory structure because it has to follow the namespace, and the Clojure code has a namespace for each source file.

So, basically I'll just upload the whole project directory to the repository.  There is a way to run the project without Leiningen, and I'll add a batch file or shell script to do that later.

I don't like the directory looking so complex, but there's not much I can do...

KY

[Russell Wallace]

2012/4/29 YKY (Yan King Yin, 甄景贤) <generic.in...@gmail.com>:

> I found out that with Java, you cannot change the directory structure
> because it has to follow the namespace

Oh yes, that's true, but you don't actually have to use namespaces. If
you have package foo.bar.baz, that's three levels of subdirectories,
but if you just have package foo that's only one subdirectory, and if
you just use the default package then no subdirectory is required.

[William Taysom]

> I started using Leinengen the Clojure project manager, but it creates a complex directory structure for the project. I'd rather the source files stay in one neat place.

What did you find complex about Leinengen? A basic project seems especially minimalistic: 4 files, 5 directories. What are you doing differently?

I'm certainly fond of simple organization schemes. When using a project system, package manager, or framework, I try to consider what the tool is doing for me, what conventions it has, what it enables, and what its real complexity costs are. I find complex default directory structure especially daunting. Depending on the situation, prescribed structure does not necessarily mean that source files won't fall into a neat place. In the best scenarios, a complex directory structure may provide a place for everything.

Consider Ruby on Rails. When you create a new Rails project, 72 files are created. That's a lot to look at and keep in mind; however, these files fix the overall structure of a Rails project. As you customize these and add your own files, there are specific places to put them. As a consequence, if you encounter an entirely new and unfamiliar Rails app, you can easily get oriented. You know where to look.

> I found out that with Java, you cannot change the directory structure because it has to follow the namespace, and the Clojure code has a namespace for each source file. ... I don't like the directory looking so complex, but there's not much I can do...

Likewise, Java's package/directory structure symmetry lets you know where every file is going to be. Sure, it seems a little silly to have your files live at src/com/domain/project/, but it's simple, regular, and works out okay for everyone.

[YKY (Yan King Yin, 甄景贤)]

The directory structure is from Leiningen.  Most people use Leiningen for Clojure projects, the alternative is Maven which is much more complication.  Or they manage dependencies manually.

I guess I'll provide the option of not installing Lein, but retain the Lein directory structure...

Later can can also compile to Javascript so web browsers can run our demos...

KY

[William Taysom]

> Most people use Leiningen for Clojure projects ... I guess I'll provide the option of not installing Lein

If most people use it, just use it.

[YKY (Yan King Yin, 甄景贤)]

OK, now there is a Clojure prototype here:

http://code.google.com/p/genifer/source/browse/#hg%2Fclojure%2Fgenifer%2Fsrc%2Fgenifer

Branch = default.

"Narrowing" is a stub.

Backward-chaining is 90% ready -- am trying to add unification to it.  (Previous version uses propositional logic only).

You can look at the simple KB in knowledge_representation.clj.  The formulas look like English so it's easy to guess their meanings.

I'm rushing to deliver the prototype before mid May.  There will be a simple bottom-up inductive learner, and a naive version of narrowing, hopefully.  The point is to have a minimal system that can learn English from examples and via hand-crafted grammar rules....

=)

KY

[Matt Mahoney]

How do you plan to test whether the program can "learn English"?

--
-- Matt Mahoney, mattma...@gmail.com

[YKY (Yan King Yin, 甄景贤)]

On Wed, May 2, 2012 at 4:09 AM, Matt Mahoney <mattma...@gmail.com> wrote:

How do you plan to test whether the program can "learn English"?

Demonstrate that it can parse simple sentences and be able to answer simple questions based on facts parsed from English and stored as logic.

The new logic is very "algebraic" in form, which can relate to your compression algorithm very well.  Basically we are using "formulas with holes" (holes = variables) to compress data.  Whereas you advocated using n-grams or the likes.  It's also similar to David Mumford's use of General Pattern Theory (see his latest book).  But I don't have a detailed analysis / comparison of the formalisms yet...

PS:  some new progress:

1.  Both forward- and backward- chaining are ready

2.  The code for narrowing has been outlined, still missing a few details

3.  For the inductive learner, I already has a top-down one written in Lisp, which would be easy to port to Clojure.  Beginning to understand the bottom-up one based on anti-unification, which is quite interesting.

KY

[Matt Mahoney]

On Wed, May 2, 2012 at 12:23 PM, YKY (Yan King Yin, 甄景贤)
<generic.in...@gmail.com> wrote:
> On Wed, May 2, 2012 at 4:09 AM, Matt Mahoney <mattma...@gmail.com>
> wrote:
>>
>> How do you plan to test whether the program can "learn English"?
>
> Demonstrate that it can parse simple sentences and be able to answer simple
> questions based on facts parsed from English and stored as logic.

A lot of questions can be answered without parsing. For example, if
the database contains "John loves Mary", then most questions like "Who
loves Mary?" could be answered just by matching terms without
considering word order. This is already a solved problem (Google), so
I guess not very interesting.

Parsing becomes more important when making inferences involving
relations between objects, such as in space, time, causality, or some
other attribute. For example, "Bob lives in New York", "New York is in
the USA", therefore Bob lives in the USA. An AI should be able to do
this, just because humans can. But I wonder if there is any value in
solving much deeper inference problems than a human could solve. The
only place where I can imagine this being true is when the component
facts are extremely reliable, such as in mathematics or programming.
But then we would be better off developing a specialized tool with a
restricted grammar like a programming language or WolframAlpha than a
general purpose natural language AI. The set of highly precise facts
is very small compared to the whole set of human knowledge.

There has been a lot of linguistic work in natural language parsing,
mostly supervised approaches to learning annotated text. Most of this
work I would consider a failure, both because the error rate is high
and because a parse tree is not the final result that we want. Solving
the parsing problem requires building a semantic model first. You have
to know what a sentence means before you can parse it. Any ideas on
how to do this?

Also, any ideas on what to use as a test database? I was thinking
Wikipedia. This was 4 GB of text in 2006, probably much larger now.


-- Matt Mahoney, mattma...@gmail.com

[Russell Wallace]

On Wed, May 2, 2012 at 7:42 PM, Matt Mahoney <mattma...@gmail.com> wrote:
> But I wonder if there is any value in
> solving much deeper inference problems than a human could solve. The
> only place where I can imagine this being true is when the component
> facts are extremely reliable, such as in mathematics or programming.

It's interesting to note that when humans solve deep inference
problems in domains where the component facts are not reliable, we do
it by integrating large volumes of weak evidence.

To expand on that, consider the amount of experience required for
high-level performance across individual domains. Smart ten-year-olds
with appropriate training can play purely formal games like chess or
Go at expert level. Slightly less formal but still technical domains
require a bit more experience, but there are still plenty of highly
capable teenage programmers. Managing a large software project or
writing a great novel requires a large enough volume of tacit
knowledge that it will rarely be done well by anyone younger than
twenty. But once you get into a domain like politics, the component
facts are so many and so unreliable, and the volume of evidence that
needs to be integrated therefore so large, that for senior political
posts a thirty-year-old is considered a wet behind the ears newbie.

Can we draw analogies to AI? I think we can. A short program with a
small database can play very good chess. But Google delivers almost
supernaturally good search results, despite not having significant
real understanding of the terms involved, by integrating a larger
volume of evidence than any unaided human brain ever could. Nor is
this an isolated case: big data is a buzzword in business computing
these days.

The conclusion, I think, is that if you want to draw deep inferences
in domains that are not very formal, this is both possible and
valuable, but it requires integration of a lot of data.