[mercury-users] Matricies

Juergen Stuber juergen at mpi-sb.mpg.de
Sun Sep 26 22:28:08 AEST 1999


Robert Ernst Johann JESCHOFNIK <rejj at cat.cs.mu.OZ.AU> writes:
> 
> I was just wondering - what is the preferred method for representing and
> storing a matrix in Mercury? An array of arrays? List of lists?

I'd also use a single array as Fergus proposed.

> I don't need to do any really complex computation on them, basically just
> simple matrix multiplication, inverse, etc.. But I'd like to do it the
> best way nevertheless.. and while I am there, I might as well do it right
> and build a decentish matrix library anyway.

That's ok if you call it `float_matrix', assuming you are writing a
library of matrices over floats (I guess that's what you are planning?).

Even better would be matrices over arbitrary rings (or fields for the
inverse), but this needs typeclasses.  The problem with this is that
it is not totally clear how the typeclass `ring' should be defined.
Putting all the operations, in particular `+' and `*', in a single
typeclass (like Num in Haskell) causes problems for vectors, since
these can be added but there is in general no product of two vectors
resulting in a vector.  So one needs to at least separate `+' and `*'
into typeclasses say `add_group' containing groups in additive
notation and on top of that `ring'.  For my own little project this
is fine, because I can change them if I want, more or less easily.
But if these get nailed down in the standard library they'd rather be
even more fine-grained, or they will restrict future developments.
In the extreme one gets typeclasses `add_semigroup', `add_monoid',
`add_group', `mul_semigroup', `mul_monoid' and `ring', which
introduce one operation at a time.  And between `ring' and `field'
there are various kinds of rings, where we need at least a typeclass
for euclidean rings.

Another problem is that strictly speaking floats do not form a field,
since their limited precision breaks various algebraic laws.  We
want to use them nevertheless, so what kind of precautions should
we take to avoid problems with rounding?

Also in the long run somebody might want to use more than one
representation for matrices, e.g. sparse representation.  To support
this, one needs a typeclass `matrix', or even a constructor class to
support the polymorphism w.r.t. the base ring.

Viele Grüße

Jürgen

-- 
Jürgen Stuber <juergen at mpi-sb.mpg.de>
http://www.mpi-sb.mpg.de/~juergen/
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list