[Haskell-cafe] matrix computations based on the GSL

Jacques Carette carette at mcmaster.ca
Thu Jun 30 09:19:08 EDT 2005


David Roundy and Henning Thielemann have been arguing about the nature 
of vectors and matrices, in particular saying:

>On Thu, Jun 30, 2005 at 02:20:16PM +0200, Henning Thielemann wrote:
>  
>
>>On Thu, 30 Jun 2005, David Roundy wrote:
>>    
>>
>>Matrices _and_ vectors! Because matrices represent operators on vectors
>>and it is certainly not sensible to support only the operators but not
>>the objects they act on ...  Adding a vector type by a library that is
>>build on top of a matrix library seems to me like making the first step
>>after the second one.
>>    
>>
>
>No, matrices operate on matrices and return matrices.  This is the
>wonderful thing about matrix arithmetic, why it's unique, and why I'd like
>to have a library that supports matrix arithemetic. 
>
The really funny thing about that exchange is that you are *both right* 
!  You're just using different interpretations of the same objects.

1) Matrices represent linear operators which naturally act (via 
application) on vectors
2) Matrices of compatible sizes, almost form a non-commutative graded 
ring.  It does not matter what a matrix represents here, this is true 
purely algebraically.  [to be a proper ring, the ``compatible sizes'' 
condition would need to be dropped]

There is a problem that the _types_ associated with both interpretations 
are quite different.  But if you want 2 different products on vectors 
(inner and outer) represented as matrices, you have no choice -- the 
``inner product'' will return a 1x1 matrix, not a real. 

The same thing is true for differential operators, BTW.  They can either 
represent actions on spaces of smooth-enough functions, or represent 
elements of a Weyl Algebra (or Ore Algebra if you really want to be 
algebraic).  You end up having the dichotomy of algebraic D-modules 
versus analytic D-modules, where they share a number of theorems, but 
the ``corner'' cases behave quite differently.

Jacques


More information about the Haskell-Cafe mailing list