Reduct design suggestions.

[linas]

Copying discussion from opencog/atomspace#2546 and specifically comment opencog/atomspace#2546 (comment)

This is a design suggestion for reduct in as-moses. Basically, it says that you don't need to use the moses reduct any more, it works (should work) in the atmspace. So for example:

The point of FloatValue and ValueOfLink is that you can do stuff like this:

 (Heaviside (Minus
    (ValueOf (Predicate "column A") (Predicate "moses column key"))
    (Plus
         (ValueOf (Predicate "column B") (Predicate "moses column key"))
         (ValueOf (Predicate "column C") (Predicate "moses column key")))))

which should return a column of 0's and 1's, whenever A>B+C row by row. The PlusLink, etc were designed to replace the moses interpreter. They mostly work. Even reduct works .. so for example

(cog-execute!
    (Plus (Number 1) 
        (Times (Variable $x) (Number 2) (Number 0.5))
        Number -1)))

should correctly reduce to exactly just (Variable $x). Many (most??) of the reduct rules are in the atomspace, already. I'll fix whatever bugs you find. I'm not sure I want to volunteer to write new reduct rules, though...

[ngeiswei]

@linas it's cool that the interpreter is able to reduce that sort of expression out of the box, however when reduction rules start to be fairly costly (which they, in principle, can be arbitrarily so) we probably won't want it to be hard wired. That is why @kasimebrahim and @Eman22S are exploring URE-based reduction. The two approaches, interpeter-hard-wired and URE-based, should be able to co-exist however.

[linas]

Yes, agreed that URE-based reduction is superior (in most ways, at least) -- its just that URE-based reduction is potentially quite difficult to implement, and risks being quite slow when implemented. Thus, for a quick, short-term fix, the hard-coded reduction works, its fast, and handles many of the common cases.

There is a large glob of mathematical literature on reduction, and you should probably read some of it -- failing to do so will create difficulties and confusion while writing the URE reduct code. A good place to start is to study "satisfiability modulo theories" (SMT). The core idea is that a "theory" is a fancy name for (roughly) "a collection of URE rules" and applying them requires a sequence of sigma-pi steps. Now might be a good time to review the sigma-pi process and have a clean design for it. I'm sure there are other interesting ideas and hints that can be gleaned from the literature. It's worth digging into.

The other thing to note: insofar as the reduct rules implement a kind-of "computer algebra system" (CAS) it would be best to split them out into their own repo, e.g. opencog/reduct or opencog/cas so that other users who might like to use this component will be able to access it, without messing with moses.

Last but not least: could you please please please, merge @kasimebrahim year-long worth of work into the opencog/asmoses master branch?

[ngeiswei]

its just that URE-based reduction is potentially quite difficult to implement

I don't think it is that difficult if the tool set is ready. @kasimebrahim and others have put a lot of effort on the tool set so far, only recently started working on URE-based reduction itself.

and risks being quite slow when implemented

That's true. However, it offers some benefits and avenues to explore. For instance

1. The way rules are combined (hand coded in MOSES) can be automated, optimized for efficiency or completeness (the main trade-off when dealing with reduction).

2. Reduction rules themselves can be inferred, based on the semantics of the operators involved. Can be quite handy when dealing with user or AI defined operators, etc.

A good place to start is to study "satisfiability modulo theories" (SMT).

Thanks for the suggestion.

The other thing to note: insofar as the reduct rules implement a kind-of "computer algebra system" (CAS) it would be best to split them out into their own repo, e.g. opencog/reduct or opencog/cas so that other users who might like to use this component will be able to access it, without messing with moses.

Yes!

It's very much experimental for now, but maybe we should do that already. I agree that atomese reduction goes far beyond MOSES.

Last but not least: could you please please please, merge @kasimebrahim year-long worth of work into the opencog/asmoses master branch?

OK. And it's probably wise to move dev back to opencog/asmoses as it only depends on opencog repos anyway. There are PRs on the fire, then I'll do the move.

[linas]

It's very much experimental for now

Brand-new git repos are great places for highly experimental code. There's no need to promise that the code works or will ever work, as long as you call it version 0.x with x less than 7 or 8.