[Haskell-cafe] vector-space and standard API for vectors
wren ng thornton
wren at freegeek.org
Tue Oct 26 18:53:46 EDT 2010
On 10/26/10 8:51 AM, Alexey Khudyakov wrote:
> On 24.10.2010 03:38, wren ng thornton wrote:
>> I don't care much about the name of the class, I'd just like support for
>> monoids, semirings,... when they lack a group, ring,... structure.
>>
> Then what about following type class hierarchy? I think it supports
> those structures. Only restriction is that it forces one to have both
> left and right modules. It's possible to split them but I think it will
> be to painful for vector spaces over R and C.
>
> class Module v where
> type Scalar v :: *
> (*^) :: Scalar v → v → v
> (^*) :: v → Scalar v → v
> (^*) = flip (*^)
Is there any good reason for forcing them together? Why not, use the
hierarchy I proposed earlier? If you want to reduce the clutter in type
signatures for real and complex vector spaces then just add to my previous
-- Or just call it "Module" if preferred.
class (LeftModule v, RightModule v) => AssociativeModule v where
-- Law: (^*) == flip (*^)
This way, when (not if) people want nonassociative modules the classes
are already there. The additional overhead in defining an associative
module is only three lines when using default implementation; two lines
otherwise:
type instance Scalar Foo = Bar
instance AssociativeModule Foo where
instance RightModule Foo where
(^*) = flip (^*)
instance LeftModule Foo where
(*^) = ...
vs
instance Module Foo where
type Scalar Foo = Bar
(*^) = ...
And once it's defined, the usage is the same: just require
AssociativeModule and you'll pull in both (*^) and (^*).
We already know that there are noncommutative modules/vectorspaces of
interest (e.g., modules over quaternions and modules over graph paths),
why not support them from the beginning? It seems like you're going out
of your way to exclude things that would be trivial to include. This is
exactly why this is my standard complaint against the various proposals
out there for new numeric hierarchies. People who are used to only using
R^n think the proposals are just fine, but none of the proposals capture
the structures I work with daily. Which means the new proposals are no
better than the Prelude for me.
--
Live well,
~wren
More information about the Haskell-Cafe
mailing list