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
class KnownNat (Dimension x) => Manifold x where
    type Dimension x :: Nat
Manifolds 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
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 package, with
size Dimension x. In general, numerical operations in Goal are defined in
terms of vector-sized and
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 Points with the following infix type synonym
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 Points in alternative coordinate
systems
class Transition c d x where
    transition :: c # x -> d # x
As an example, where we define Euclidean space
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
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
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.