ILP not in Prolog?!

Anyone familiar with ILP (Inductive Logic Programming) probably knows that
it is a very Prolog-centric idea. ILP systems generate Prolog programs,
they use Prolog programs as background knowledge, training data is provided
in Prolog, and the induction phase itself uses many facilities built into
Prolog.

That's why I was surprised to find out that both ILP systems that I've heard
of (FOIL6 and PROGOL) are now [re-]written in C! The source code is, of
course, huge and looks completely unreadable, compared to, for example,
earlier FOIL in Prolog.

I consider ILP to be one of the most interesting achievements of AI, and one
of the most exemplary applications of Prolog, so why was C chosen as a host
language for it? Compiler availability can't possibly be an issue, because
Prolog programs are still used as input and output.

alex goldman wrote:
> Anyone familiar with ILP (Inductive Logic Programming) probably knows that
> it is a very Prolog-centric idea. ILP systems generate Prolog programs,
> they use Prolog programs as background knowledge, training data is provide
d
> in Prolog, and the induction phase itself uses many facilities built into
> Prolog.
>
> That's why I was surprised to find out that both ILP systems that I've hea
rd
> of (FOIL6 and PROGOL) are now [re-]written in C! The source code is, of
> course, huge and looks completely unreadable, compared to, for example,
> earlier FOIL in Prolog.
>
> I consider ILP to be one of the most interesting achievements of AI, and o
ne
> of the most exemplary applications of Prolog, so why was C chosen as a hos
t
> language for it? Compiler availability can't possibly be an issue, because
> Prolog programs are still used as input and output.

Here in Leuven we also have an ILP system based on Prolog - our own Prolog
system named hipP (descendant of ilProlog - name change because of spin-off
related legal paperwork avoidance). The main parts are in Prolog, but parts
that used to be in Prolog in the beginning, sometimes are rewritten in C;
usually for performance reasons.

The answer to the question "why rewriting in C ?" can start with answering
another question: "why was it initially in Prolog ?". Because at first nothi
ng
was totally clear: not how to do it, what to do exactly, what would work fin
e,
what functionality was really needed etc. And then Prolog is a very good too
l
to use. After a while one understands the implementation issues, one knows w
here
performance bottlenecks are, one sees perhaps that some of the extra possibi
lities
that Prolog offers (in the ILP tool in this case) might be redundant for mos
t
applications etc (or at least one thinks one knows all these things);
as an extra motivation to rewrite in C: there are large numbers of C program
mers
(and one thinks they will be able to enhance/maintain the C version, while t
he
Prolog version could have been a 3 people's job; these Prolog people are lea
ving
or lost interest, and there is no big pool of Prolog programmers); customers
have heard of C and distrust Prolog; same with the managers; it will speed u
p
the ILP tool ... so many good looking reasons for rewriting in C.

It is the same  old story over and over again. Here is something I took f
rom
this newsgroup some years ago (in response to a question similar to yours, b
ut not
ILP related):

% You build a Prolog (or Lisp, or ML, or ...) prototype that is a bit
% too slow for production use, and the Powers That Be decide to recode
% it all in C++ in order to make it 4 times faster.
%
% Unfortunately, the rewrite project takes two years, makes the
% resulting system less powerful, only gets a 3-fold speedup, and this
% expensive project has a 60% chance of failure due to battles between
% developers with brittle personalities over which subset of C++ to use.

and another one:

% Usually it goes like this: a prototype is quickly made in a high
% level language, the prototype works beautifully, the pointy haired
% managers want the product in C++, the prototype is converted in
% C++, it takes years, at the end it doesn't work, the project is canned,
% millions are wasted, then the managers go to conferences about
% the Software Crisis.

Cheers

Bart Demoen

Bart,

On 2005-04-01, Bart Demoen <bmd@cs.kuleuven.ac.be> wrote:
> It is the same  old story over and over again. Here is something I took
 from
> this newsgroup some years ago (in response to a question similar to yours,
 but not
> ILP related):
>
> % You build a Prolog (or Lisp, or ML, or ...) prototype that is a bit
> % too slow for production use, and the Powers That Be decide to recode
> % it all in C++ in order to make it 4 times faster.
> %
> % Unfortunately, the rewrite project takes two years, makes the
> % resulting system less powerful, only gets a 3-fold speedup, and this
> % expensive project has a 60% chance of failure due to battles between
> % developers with brittle personalities over which subset of C++ to use.
>
> and another one:
>
> % Usually it goes like this: a prototype is quickly made in a high
> % level language, the prototype works beautifully, the pointy haired
> % managers want the product in C++, the prototype is converted in
> % C++, it takes years, at the end it doesn't work, the project is canned,
> % millions are wasted, then the managers go to conferences about
> % the Software Crisis.

You should modernise the story: sed 's/C++/Java/g'

Otherwise, this appears to be the way the world works. Look at it from
the bright side though. We have a nice innovative job building great
prototypes! Even for the business this is good: they do not spent too
much resources in the high-risc phase getting the initial system up and
finding initial customers. Being quick also gives them the leading edge
in fighting a new market.

Prolog is a great tool for prototyping and systems with a small install-base
.
Technically it may be fit for much more, but I would be surprised if we'll
see this happen.  No worries though.  There are a lot of things to prototype
and a lot of applications with a very small install-base.

Cheers --- Jan

P.s.	With Java, two of the reasons to move to C++, speed and smaller
footprint have gone.  I guess the really dominant reasons are
choosing for `mainstream' and shortage of Prolog programmers.

Bart Demoen wrote:

> After a while one understands the implementation issues, one knows where
> performance bottlenecks are, one sees perhaps that some of the extra
> possibilities that Prolog offers (in the ILP tool in this case) might be
> redundant for most applications etc (or at least one thinks one knows all
> these things);

Yes, I'm actually very curious about the ILP-specific reasons for dumping
Prolog. It seems like implementing ILP in C should require reimplementing a
good deal of Prolog itself in C: unification, backtracking, compiler (for
performance), the whole deal, no?

In case anyone interested, last time I looked at the Edward R. Hamilton
overstock book site a few days ago,  there was book on ILP from MIT press on
sale.

Tak


"alex goldman" <hello@spamm.er> wrote in message
news:11244434.6Y6TW93Gu1@yahoo.com...
> Anyone familiar with ILP (Inductive Logic Programming) probably knows that
> it is a very Prolog-centric idea. ILP systems generate Prolog programs,
> they use Prolog programs as background knowledge, training data is
> provided
> in Prolog, and the induction phase itself uses many facilities built into
> Prolog.
>
> That's why I was surprised to find out that both ILP systems that I've
> heard
> of (FOIL6 and PROGOL) are now [re-]written in C! The source code is, of
> course, huge and looks completely unreadable, compared to, for example,
> earlier FOIL in Prolog.
>
> I consider ILP to be one of the most interesting achievements of AI, and
> one
> of the most exemplary applications of Prolog, so why was C chosen as a
> host
> language for it? Compiler availability can't possibly be an issue, because
> Prolog programs are still used as input and output.

alex goldman wrote:
> Anyone familiar with ILP (Inductive Logic Programming) probably knows that
> it is a very Prolog-centric idea. ILP systems generate Prolog programs,
> they use Prolog programs as background knowledge, training data is provide
d
> in Prolog, and the induction phase itself uses many facilities built into
> Prolog.
>
> That's why I was surprised to find out that both ILP systems that I've hea
rd
> of (FOIL6 and PROGOL) are now [re-]written in C! The source code is, of
> course, huge and looks completely unreadable, compared to, for example,
> earlier FOIL in Prolog.
>
> I consider ILP to be one of the most interesting achievements of AI, and o
ne
> of the most exemplary applications of Prolog, so why was C chosen as a hos
t
> language for it? Compiler availability can't possibly be an issue, because
> Prolog programs are still used as input and output.

Hi there,

As ILP has been roughly defined as the intersection ML \cap LP
(where: ML = Machine Learning and LP = Logic Programming)
it seems clear that LP (i.e. Prolog)
is only the target representation for the inferred concepts.

Actually, there's plenty of other representations for multi-relational
knowledge.
Yet, it may be natural to apply LP to reason in LP
but that can be done (more efficiently?)
in procedural languages like C as well.

(btw once I wrote an ILP system (in C) that learns clauses expressed in
Michalski's VL21 language.)

cheers

Nico

Bart Demoen a écrit :
> alex goldman wrote:
>
...
> as an extra motivation to rewrite in C: there are large numbers of C
> programmers
> (and one thinks they will be able to enhance/maintain the C version,
> while the
> Prolog version could have been a 3 people's job; these Prolog people are
> leaving
> or lost interest, and there is no big pool of Prolog programmers);

I think is subsumed by goldman's question, the question whether any C/Java
programmer can be expected to understand/enhance/maintain any implementation
of ILP without being knowledgeable in Prolog.