# goal-geometry: The basic geometric type system of Goal

[ bsd3, library, math ] [ Propose Tags ]

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.  #### Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

• No Candidates
Versions [RSS] 0.1, 0.20 ad, base (>=4.13 && <4.15), ghc-typelits-knownnat, ghc-typelits-natnormalise, goal-core, indexed-list-literals [details] BSD-3-Clause Sacha Sokoloski sacha.sokoloski@mailbox.org Math https://gitlab.com/sacha-sokoloski/goal by alex404 at 2021-08-31T16:06:36Z NixOS:0.20 3 direct, 0 indirect [details] 918 total (0 in the last 30 days) (no votes yet) [estimated by Bayesian average] λ λ λ Docs uploaded by user All reported builds failed as of 2021-08-31

[back to package description]

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.