The basic geometric type system of Goal.
goal-geometry provides the basic types and classes which drive the manifold/geometry based approach of Goal. Points and manifolds, dual spaces, function spaces and multilayer neural networks, and generic optimization routines are defined here.
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.