Hi Reiner,
Fantastic work! User-friendly static dimension checking is an essential
feature for any decent linear algebra library. Your interface using
quasiquotation and view patterns is very elegant and practical. I am
happy that hmatrix is useful, but I'm afraid that its primitive dynamic
interface will no longer be used :)
Many thanks for your excellent work!
Alberto
Reiner Pope wrote:
There should be essentially no performance penalty in going from
hmatrix to hmatrix-static, for most functions. The Vector and Matrix
types I define are just newtypes of hmatrix's Vector and Matrix types,
so they will have the same runtime representation.
There are a few cases where performance could potentially differ,
described below.
Reflecting and reifying Ints (i.e. converting between types and values):
(The ideas for this come from the Implicit Configurations paper[1].)
Some Int arguments in hmatrix have been written as types in
hmatrix-static, such as the function "constant".
hmatrix type:
constant :: Element a => a -> Int -> Vector a
hmatrix-static type:
constant :: (Element a, PositiveT n) => a -> Vector n a
The PositiveT constraint is essentially a way of passing the Int
parameter as an implicit parameter. To demonstrate this, we use two
library functions which allow us to convert from Ints to types with
PositiveT constraints, and back:
value :: PositiveT n => Proxy n -> Int -- type -> value
reifyPositive :: Int -> (forall n. PositiveT n => n -> r) -> r --
value -> type.
The use of these functions is nice in some cases, such as "constant"
above, because it allows us to pass parameters implicitly. On the
other hand, the conversion between types and values imposes an O(log
n) cost, where n is the size of the number we are converting. In my
experience, this cost has not been significant (although it was
previously, when I used a naive O(n) reifyIntegral implementation!).
Newtype conversion costs:
Occasionally, unwrapping newtypes can actually have a runtime cost.
For instance, the hmatrix-static function
joinU :: Storable t => [Vector Unknown t] -> Vector Unknown t
needs to do a conversion :: [Vector Unknown t] -> [HMatrix.Vector t].
Now, the conversion "unwrap :: Vector Unknown t -> HMatrix.Vector t"
is a noop, as it unwraps a newtype. However, to get the list
conversion, we need to do "map unwrap", which requires mapping a noop
over a list. However, because of map's recursion, GHC may not be able
to recognise that "map unwrap" is a noop, and traverse the list
anyway, causing a performance loss.
However, there aren't many recursive data structures used in
hmatrix-static, so this problem mostly doesn't exist.
Cheers,
Reiner
[1] http://okmij.org/ftp/Haskell/types.html#Prepose
On Sun, Apr 12, 2009 at 12:18 PM, Xiao-Yong Jin <[email protected]> wrote:
Reiner Pope <[email protected]> writes:
Hi everyone,
I am pleased to announce hmatrix-static[1], a thin wrapper over
Alberto Ruiz's excellent hmatrix library[2] for linear algebra.
The main additions of hmatrix-static over hmatrix are:
- vectors and matrices have their length encoded in their types
- vectors and matrices may be constructed and destructed using view
patterns, affording a clean, safe syntax.
hmatrix-static includes statically-sized versions of hmatrix's linear
algebra routines, including:
- simple arithmetic (addition, multiplication, of matrices and vectors)
- matrix inversion and least squares solutions
- determinants / rank / condition number
- computing eigensystems
- factorisations: svd, qr, cholesky, hessenberg, schur, lu
- exponents and sqrts of matrices
- norms
See http://code.haskell.org/hmatrix-static/examples/ for example code.
This is quite interesting. I would like to know the
performance penalty of such a wrapper. I'll test it by
myself when I've got time. But can you give me some idea of
how such a wrapper can be optimized by ghc in terms of space
and time performance?
--
c/* __o/*
<\ * (__
*/\ <
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
