Scalar versus Functorial

[tonyday567]

Turning my attention to ocramz/sparse-linear-algebra#60

Interpreted for numhask naming conventions, the library defines this:

class (Subtractive a, Multiplicative (Scalar a)) => VectorSpace a where
  type Scalar a :: *
  (.*) :: Scalar a -> a -> a

class VectorSpace a => InnerSpace a where
  (<.>) :: a -> a -> Scalar a

The current numhask approach is to "push" the Scalar (or Element) type to the headline, and eschew the Scalar type inside the class definition:

class (Multiplicative a) => MultiplicativeAction r a where
  (.*) :: r a -> a -> r a

class (Ring a, Divisive (r a), MultiplicativeAction r a) => Module r a

class (Module a) => Hilbert r a where
  (<.>) :: r a -> r a -> a

https://en.wikipedia.org/wiki/Vector_space

Conversion would be straight forward.

instance (MultiplicativeAction r a) => VectorSpace (r a) where
  type Scalar (r a) :: a
  (.*) = coerce (flip (.*))

instance (VectorSpace v) => MultiplicativeAction a (Scalar a) where
  (.*) = coerce (flip (.*))

My (outdated by now) experience with Scalar in subhask was that it caused a lot of constraint explosion for no good reason - plenty of Scalar s ~s etc. In sla, there is also:

class (Eq e , Fractional e, Floating e, Num (EltMag e), Ord (EltMag e)) => Elt e where
  type EltMag e :: *

which tends to be unnecessary in numhask.

Having said this, I'm wide open for potential solutions, from status quo, to having both, to going with Scalar etc etc.

[ocramz]

@tonyday567 very interesting, thank you for your insight! Yes I agree the Scalar type family really looks like poor design, I didn't come up with anything better at the time.

[tonyday567]

Not so fast at hitting the self-deprecation button! It's the boiler-plate solution for every other higher-kinded number library out there.

If you have like a Matrix 3 3 Int and you want to treat that as composed of 3 Vector 3 Ints, in other words, you want to be able to say m .* v, then you can say instance VectorSpace (Matrix 3 3 Int); type Scalar m = Vector 3 Int. The numhask way would be instance MultiplicativeAction (Vector 3) (Vector 3 Int). First way adds flexibility.

[LeanderK]

I agree. It's very inflexible because it enforces a hard design-constraint on your type and could lead to very convoluted types if you have a complicated scalar. Also, some types just may not fit the pattern.

I like your example of @tonyday567. What you want to construct is usually seen as a direct sum of vector-spaces (where we view the matrix as a sum of vectors). We ideally want to express both things, but I think for the later, the direct sum, the abstraction is too liberal. The type of the scalar and the type of the thing must not go out of sync (when doing matrix-multiplication etc.), which could lead to bugs and in general, seems like a very fragile solution.