[racket] math/matrix

On May 14, 2014, at 10:40 AM, Jens Axel Søgaard <jensaxel at soegaard.net> wrote:

> 2014-05-13 23:24 GMT+02:00 Matthias Felleisen <matthias at ccs.neu.edu>:
>> On May 13, 2014, at 4:19 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
>>> We need a predicate like
>>> 
>>> (: flonum-matrix? (All (A) (-> (Matrix A) Boolean : (Matrix Flonum))))
>> 
>> 
>> I think in our world of types we could even have
>> 
>> (: flonum-matrix? (All (A) (-> (Matrix A) Boolean : (TriangularMatrix A))))
>> 
>> and such and then dispatch to even more special solvers. It's kind of like a number hierarchy generalization. Just a thought.
> 
> I think it was a mistake to represent matrices simply as naked arrays.
> 
> If the representation were
> 
>   (struct matrix (representation-type representation properties))
> 
> then one could take advantage of the properties of the matrix.
> 
> E.g. for a symmetric matrix it is enough to store the upper triangular
> part (the same goes for a triangular matrix).
> 
> This would also allow mixing computation between ones representated
> as two dimensional arrays and LAPACK ones.
> 
> Problems using a dispatch based on inspecting the matrix values:
>  *  there are two many interesting properties to check
>     (symmetric, hermition, upper/lower-triangular, sparse)
>  * times saved is less than the time used to check
>    (consider the case of adding two symmetric matrices)


In a typed world you could probably get rid of _almost all_ run-time costs. That's what I am saying. You provide constructors that create matrices of the right kind, the overloaded functions on matrices come with types such as +'s to keep track of properties where possible, and when you claim a regular Matrix is a Triangle, you pay -- but that's pay as you go and convenient in occurrence typing. I am sure computational scientists will understand the last step, and Vincent can help them 

-- Matthias