Can ILP learn geometry rules with floating point numbers

General
13

The parent thread also contains declarative and procedural views
of @stassa.p Louise ILP systems. Pitty these posts didn’t
land in this new thread here, mostlikely they are a beginning to

understand how the Hypothesis Space is searched:

What I did with the logical explanation that a hypothesis
K = (H :- B) can derive H from B via Modus Ponens, and how
it is procedurally shown in your algorithm 1, is the classical

switch between these two views of Prolog:

  • Declarative View (What is true): Focuses on the logical meaning
    (the “model”) of the code. A rule H :- B means " H is true if B is true".
    It ignores the order of rules and goals.

  • Procedural View (How it works): Focuses on the sequence of operations.
    The rule H :- B means “To solve H, first solve B”. It depends heavily on the
    ordering of clauses and goals (top-to-bottom, left-to-right).

Your algorithm 1 is just a capsule of “To solve H, first solve B”. I think practically
ILP has also a procedural aspect not only an appraisal of a declarative
view, and it somehow determines which hypothesis you list first.

Bye asking HOW is the Hypothesis Space refined, I didn’t wanted to know
WHAT ILP does, it was already shown in the parent thread, but HOW it
finds Hypothesis, in particular in what order and whether the end user

can have preferences. I suspect your higher order input to Louise
changes the found Hypothesis, if you reorder the higher order input,
right? I didn’t try yet, but I guess so, right? What search order does your

“2nd order SLD / MIL” implement when it searches the Hypothesis Space?
It seems the naive view of algorithm 1 is anyways not correct, since
there are algorithms 2, 3, 4, .. Louise does extend the end-user

given higher order templates anyways through heuristics?

BTW: A possible answer could be input order of examples followed
by input order of rule patterns. But I am not 100% sure whether Louise
for example implements that. But algorithm 1 looks a little bit like that,

but pratically it could be also the other way around, rule patterns followed
by examples. Traditionally Prolog itself works with input order, the clauses
of a predicate are executed from top to bottom, even indexing doesn’t

change that. SLG resolution would change the order a little bit, through
worker queues. But comming back to Louise, so maybe I could influence
the result of Louise by also shuffling the examples?