In this package we find all the basic types and classes which drive the
manifold/geometry based approach of Goal. In particular, points and manifolds,
dual spaces, function spaces and multilayer neural networks, and generic
optimization routines such as gradient pursuit. What follows is very brief
introduction to how we define points on a manifold in Goal.
The fundamental class in Goal is the `Manifold`
```haskell
class KnownNat (Dimension x) => Manifold x where
type Dimension x :: Nat
```
`Manifold`s have an associated type, which is the `Dimension` of the `Manifold`.
The `Dimension` of a `Manifold` tells us the size required of vector to
represent a 'Point's on the given `Manifold`. In turn a `Point` is defined as
```haskell
newtype Point c x =
Point { coordinates :: S.Vector (Dimension x) Double }
```
At the value level, a `Point` is a wrapper around an `S.Vector`, which is a
storable vector from the
[vector-sized](https://hackage.haskell.org/package/vector-sized) package, with
size `Dimension x`. In general, numerical operations in Goal are defined in
terms of [vector-sized](https://hackage.haskell.org/package/vector-sized) and
[hmatrix](https://hackage.haskell.org/package/hmatrix), with specific functions
for applying operations in bulk. Although I make no promises, Goal should be
quite efficient, at least for a CPU-based numerical library.
To continue, a `Point` is defined at the type-level by a `Manifold` `x`, and the
mysterious phantom type `c`. In Goal `c` is referred to as a coordinate system,
or more succinctly as a chart. A coordinate system describes how the abstract
elements of a `Manifold` may be uniquely represented by a vector of numbers. In
Goal we usually refer to `Point`s with the following infix type synonym
```haskell
type (c # x) = Point c x
```
which we may read as a `Point` in `c` coordinates on the `x` `Manifold`. I chose
the `#` symbol because it is reminiscent of the grid of a coordinate system.
Finally, with the notion of a coordinate system in hand, we may definition
`transition` functions for re-representing `Point`s in alternative coordinate
systems
```haskell
class Transition c d x where
transition :: c # x -> d # x
```
As an example, where we define `Euclidean` space
```haskell
data Euclidean (n :: Nat)
instance (KnownNat n) => Manifold (Euclidean n) where
type Dimension (Euclidean n) = n
```
and two coordinate systems on Euclidean space with an appropriate transition function
```haskell
data Cartesian
data Polar
instance Transition Cartesian Polar (Euclidean 2) where
{-# INLINE transition #-}
transition p =
let [x,y] = listCoordinates p
r = sqrt $ (x*x) + (y*y)
phi = atan2 y x
in fromTuple (r,phi)
```
we may create a `Point` in `Cartesian` coordinates an easily convert it to `Polar` coordinates
```haskell
xcrt :: Cartesian # Euclidean 2
xcrt = fromTuple (1,2)
xplr :: Polar # Euclidean 2
xplr = transition xcrt
```
So what has this bought us? Why would we make use of not only one, but
essentially two phantom types for describing vectors? Intuitively, the
`Manifold` under investigation is what we care about. If, for example, we
consider a `Manifold` of probability distributions, it is the distributions
themselves we care about. But distributions are abstract things, and so we
represent them in various coordinate systems (e.g. mean and variance) to handle
them numerically.
The charts available for a given `Manifold` are thus different (but isomorphic)
representations of the same thing. In particular, many coordinate systems have a
dual coordinate system that describes function differentials, which is critical
for numerical optimization. In general, many optimization problems can be
greatly simplified by finding the right coordinate system, and many complex
optimization problems can be solved by sequence of coordinate transformations
and simple numerical operations. Numerically the resulting computation is not
trivial, but theoretically it becomes an intuitive thing.
For in-depth tutorials visit my
[blog](https://sacha-sokoloski.gitlab.io/website/pages/blog.html).