| Copyright | (c) Tom Harding 2020 |
|---|---|
| License | MIT |
| Safe Haskell | Safe-Inferred |
| Language | Haskell2010 |
Data.Input.Config
Description
Simplistically, search problems are solved by running the computation with different input combinations, looking for any combinations that satisfy the constraints. In reality, we play some tricks to avoid running every possible input combination, but the principle is the same:
This module exposes the Config type, which stores an initial assignment for
the input parameters (typically something close to mempty), and a function
that generates possible refinements for those inputs.
For example, we might have a variable we know must be a number between 1 and
10. A good initial value for this might be a mempty value such as
Unknown, with the refinements being Exactly
the ten possible values.
The initial values are first fed into the computation before the propagators are established. Sometimes, these initial propagators can produce new information (such as advancing a few steps forward in a sudoku puzzle) before we even start to refine the inputs. The benefit here is that we can sometimes discover that a variable's search space is smaller than we realise, and so we end up with much less work to do!
Documentation
data Config (m :: Type -> Type) (x :: Type) Source #
An input configuration.
This stores both an initial configuration of input parameters, as well as
a function that can look for ways to refine an input. In other words, if
the initial value is an Data.JoinSemilattice.Intersect of [1 .. 5], the
refinements might be singleton values of
every remaining possibility.
class Input (x :: Type) where Source #
The simplest way of generating an input configuration is to say that a
problem has m variables that will all be one of n possible values. For
example, a sudoku board is 81 variables of 9 possible values. This class
allows us to generate these simple input configurations like a game of
countdown: "81 from 1 .. 9, please, Carol!"
Associated Types
Different parameter types will have different representations for their
values. The Raw type means that I can say 81 , and have
the parameter type determine how it will represent from [1 .. 9]1, for example. It's
a little bit of syntactic sugar for the benefit of the user, so they don't
need to know as much about how the parameter types work to use the
library.