Port grakn sudoku-solver example

[krishnangovindraj]

What is the goal of this PR?

Port the grakn sudoku-solver to typeql and add as an example.
Distill the schema & queries to the most basic form which also works with the reasoner planner's cost model.

What are the changes implemented in this PR?

• Port the schema & data files to typeql
• Port the java driver to python & update the embedded queries to typeql
• Simplify & Optimise the schema & queries.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.

[krishnangovindraj]

Add review so that we change the package structure to the standard two-level package

[krishnangovindraj]

Blocked: The sudoku tests will fail till it's run against the improved reasoner planner.

[flyingsilverfin]

Ok so I've had a look over this, questions:

1. Is it still a interpretable/useful/meaningful sudoku solver if we write the problem statement with permutation generator without a type for row and column etc? I imagine we can introduce row/column passthroughs that generate from permutations if we wanted to?
2. Do we still need the connector-hack? This isn't a great thing to see in an example...
3. The architecture isn't quite right. "Driver" isn't a great name. I think you could have an entry point called sudoku_solver.py. You can put the current "Solver" in a typedb_sudoku.py file. The reading of input files etc. should be handled in the solver, and the typedb_sudoku.py should implement the actual communication with TypeDB and solving? What do you think?

[flyingsilverfin]

we should pin a verison number

[krishnangovindraj]

@flyingsilverfin

Is it still an interpretable/useful/meaningful sudoku solver if we write the problem statement with permutation generator without a type for row and column etc? I imagine we can introduce row/column passthroughs that generate from permutations if we wanted to?

If we use rules, our planner can't tell the difference because of how the AnswerCountEstimator estimates inferred things.

Do we still need the connector-hack? This isn't a great thing to see in an example...

As of now, we do. Without it we don't pick the best plan in the top level.
I took a deeper look and we scaled down resolvable-estimates based only on the single most scaling variable, rather than on all of them (Another assumption which seems reasonable for tree structured graphs). That's making the scaling way off. At this point, I'm surprised this worked at all.