joshmarlow / ai_kit-rs Goto Github PK

• Update README to describe project goals
  • Flexible and performant
• Describe core traits
• Document Datum and Rule
• Document how to use core algorithms with Datum and Rule
  • Provide small example of using something other than Datum

This will allow implementation of many-to-many relationships in a triple store.

https://docs.rs/ai_kit

Currently there is some ugly s-expression parsing/generation code that I would like to replace with serde for serialization/deserialization.

This will involve reworking many tests.

Investigate using Skeptic to ensure that code examples are buildable https://github.com/brson/rust-skeptic

Probably Travis CI

Not all features of the library will be needed by all application. Features that would be nice to add:

with-planner - controls if the planner module is built
with-inference - controls if the infer module is built
with-datum - controls if the datum module is built
with-constraint - controls if the constraints module is built
with-pedigree - controls if the pedigree module is built

Make it faster! The initial implementation was built as fast as possible and so uses a probably very inefficient algorithm.

Currently we can only specify the relations among numbers in the constraint library.
It would be nice if we could handle cases like this:

Ensure that one datetime is greater than another.
Ensure that the difference between two datetimes is greater than some amount.
Ensure that two variable values (as strings) are not the same.

This can probably be done by replacing the Unify trait with a custom ConstraintValue trait. Ideally we could just lean into PartialOrd, Add, etc traits for this. However, the fact that datetimes cannot be added (but time deltas can be!) complicates this. ConstraintValue might should just wrap datetime handling, but the semantics of adding datetimes is not obvious.

Open questions

PApply - (how) does it relate to Apply? Probably not.
If we allow Apply::apply to return multiple results, then we could just encode the probabilities into each U that is constructed.

Related Tickets

Rule application should support more expressive logic
Constraints should express more than numerical relations

• Should be standalone test binary
• Should be ran during CI build
• Should be visible within docs
  • Can be auto-inserted into markdown file?

Currently infer::Rule implements the Apply trait's apply method by just checking if all arguments match the provided data.

This effectively means that the preconditions for a Rule form a conjunction. It would be better if we could express all of boolean logic - conjunctions, disjunctions and negations to capture more complex rules.

I'm leaning toward a rule always having a fixed list of 'inputs', and some logic indicating 'trigger' patterns for those inputs.