Re: [Haskell-cafe] Re: Patrick Perry's BLAS package

[Patrick Perry]

a function like foo :: (BLAS1 e) => Matrix (m,n) e ->
Matrix (n,k) e -> Int -> Vector m e foo a b i = let x =
row b i in a <*> x will not type-check. (”<*>” is the
function to multiply a matrix by a vector. Everything is
ok if you replace “row” by “col”.) This feature has caught
a few bugs in my code.


If I understand this correctly, the compiler can catch
dimension mismatches so that using `col' will result in a
compilation error when m and k are different, is it so?


Yes, the compiler infers the type of expression to be

Matrix(m,n) e -> Matrix (l,m) e -> Int -> Vector n e

which is different from the declared type.  The error will be  
something like "Expected type Vector m e, but got type Vector a1 e  
instead".



I haven't look through the code, yet.  But it looks like
there are certain levels of similarities between blas and
hmatrix.  Is it possible for these two libraries to
cooperate well with each other?  (I didn't look at HBlas, so
can't say much about that.)


This is more work than you might think.  The data structures are  
different, many of the function names are different, and the module  
namespaces overlap.  I wouldn't recommend any switch from hmatrix to  
blas right now unless you really need mutable types-- hmatrix has a  
lot more linear algebra functionality.



Apart from some warnings, the library compiles fine in my
system.  But there is a minor issue about the library it
links against when `./Setup test'.  I need to use `-lcblas'
instead of `-lblas' to get it to link to correct libraries.
I don't know other people's system.  But in my system,
Gentoo Linux, I use blas library provided by atlas, and
libblas.so is a fortran library and libcblas.so is for C.


I don't know of a good way to get around this.  It seems like every  
system has a different convention for the location and name of the  
cblas libraries.  So, everyone has to edit the "extra-libraries" and  
the "extra-lib-dirs" field in the blas.cabal file.  Does anyone know  
of a better way of doing this?



Patrick

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Question about kinds

[Klaus Ostermann]

Why does the code below not pass the type checker?

If I could explictly parameterize y with the type constructor Id (as e.g. in
System F), then 'y Id' should have the type Int -> Int
and hence "y Id x" should be OK, but with Haskell's implicit type parameters
it does not work.

So, how can I make this work?

Klaus


type Id a = a

x :: Id Int
x = undefined

y :: (a Int) -> (a Int)
y = undefined

test = y x

Error:
  Couldn't match expected type `a Int' against inferred type `Id Int'
  In the first argument of `y', namely `x'
  In the expression: y x
  In the definition of `test': test = y x


-- 
View this message in context: 
http://www.nabble.com/Question-about-kinds-tp17701553p17701553.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Patrick Perry's BLAS package

[Andrzej Jaworski]

Hi,

Indeed, this has been long awaited. Long live Patrick!!!
And continue the good work:-)

However, such essential work shouldn't be dependent on heroic effort of an
individual. If Haskell is to remain non-commercial a disciplined community
effort should be taken akin to Pythonian. Perhaps also thouse of you who teach
Haskell could better use cheap labour of students,
after all Haskell's module system is not all that weak;-)

Cheers,
-A.J.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Design your modules for qualified import

[Jan-Willem Maessen]

On Jun 6, 2008, at 12:54 PM, Henning Thielemann wrote:



On Fri, 6 Jun 2008, Achim Schneider wrote:


Jan-Willem Maessen <[EMAIL PROTECTED]> wrote:


There's one caveat: Always choose descriptive names, even if you are
assuming that you will usually use a qualified import.  The
following are wonderful names, even though they conflict with the
prelude: null
  filter
  map
  lookup


import Prelude as P


Precisely.  If I import the prelude qualified and your library  
unqualified, is my code readable?  I should hope it is.  And if the  
library used the overlapping names reasonably, you shouldn't be left  
wondering when you read my code.



The following are terrible names:
  T
  C


Not to mention that this usage is hideously confusing while looking  
at

the haddock docs.


But that will be resolved when Haddock can show identifiers with
qualifications.


I specifically *didn't* bring up the Haddock issue, because I think  
it's a side show.  Fundamentally, these types are neither clear nor  
descriptive.  Their treatment by one or another documentation tool is,  
at some level, beside the point.



It's good to have fine grained modules, because you can more easily
exchange the parts you want different from the standard way. For  
reducing
import lists for simple songs I think we could provide wrapper  
modules.


Make your modules as small as you like; small modules are great.  But  
keep things readable, please!


-Jan



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Patrick Perry's BLAS package

[Xiao-Yong Jin]

(Sorry, Patrick.  I forgot to CC haskell-cafe.)

Salute!  Excellent!

Patrick Perry <[EMAIL PROTECTED]> writes:

> Wow, thanks for noticing, Alberto!  For anyone interested, I put up a
> formal announcement describing the bindings a little bit here:
>
> http://quantile95.com/
>
> I just registered the domain yesterday, so it may take a few days to
> resolve the DNS magic.  Here's the text of the announcement:
>

The magic is working, now.

>
> I’m really happy that people seem to be interested in the
> library. Alberto, in particular, is the primary author of hmatrix,
> another  haskell linear algebra library (which I stole a few ideas
> from), so if  he endorses it, that means a lot to me.
>
> So, Yet Another Linear Algebra Library? I’ve already mentioned
> hmatrix. There’s also another one called HBlas. Why would anyone want
> a third? Here are my reasons:
>
>   * Support for both immutable and mutable types. Haskell tries
> to make you use immutable types as much as possible, and indeed there
> is a  very good reason for this, but sometimes you have a 100MB
> matrix, and  it just isn’t very practical to make a copy of it every
> time you  modify it. hmatrix only supports immutable types, and HBlas
> only  supports mutable ones. I wanted both.

I didn't use hmatrix a lot, because I wrote some STUArray
things and I wasn't sure what to do with that.  However, I
just noticed that there is a bunch of ST growing under
Data.Packed in hmatrix.  Guess things is going to change,
soon.  And perhaps with your work, Alberto doesn't need to
reinvent the wheel anymore.

> 
>   * Access control via phantom types. When you have
> immutable and mutable types, it’s very annoying to have
> separate functions for each type. Do I want to have to
> call “numCols” for immutable matrices and “getNumCols” for
> mutable ones, even though both functions are pure, and
> both do exactly the same thing? No. If I want to add an
> immutable matrix to a mutable one, to I want to first call
> “unsafeThaw” on the immutable one to cast it to be
> mutable? No. With the phantom type trick, you can get
> around this insanity. Jane Street Capital has a very good
> description of how this works.  

Lovely!

> * Phantom types for matrix and vector shapes. This is a
> trick I learned from darcs. It means that the compiler can
> catch many dimension-mismatch mistakes. So, for instance,
> a function like foo :: (BLAS1 e) => Matrix (m,n) e ->
> Matrix (n,k) e -> Int -> Vector m e foo a b i = let x =
> row b i in a <*> x will not type-check. (”<*>” is the
> function to multiply a matrix by a vector. Everything is
> ok if you replace “row” by “col”.) This feature has caught
> a few bugs in my code.

If I understand this correctly, the compiler can catch
dimension mismatches so that using `col' will result in a
compilation error when m and k are different, is it so?

>
> LAPACK support is on the horizon, but that may take awhile. Also, I
> probably won’t do more than SVD, QR, and Cholesky, since those are all
> I need. Expect a preliminary announcement by the end of the summer.
>
> This work would not have been possible without looking at the other
> excellent linear algebra libraries out there. In particular the GNU
> Scientific Library was the basis for much of the design. I also drew
> inspiration from hmatrix and the haskell array libraries.
>
> Please let me know if you have any success in using the library, and
> if you have any suggestions for how to make it better.

I haven't look through the code, yet.  But it looks like
there are certain levels of similarities between blas and
hmatrix.  Is it possible for these two libraries to
cooperate well with each other?  (I didn't look at HBlas, so
can't say much about that.)

Apart from some warnings, the library compiles fine in my
system.  But there is a minor issue about the library it
links against when `./Setup test'.  I need to use `-lcblas'
instead of `-lblas' to get it to link to correct libraries.
I don't know other people's system.  But in my system,
Gentoo Linux, I use blas library provided by atlas, and
libblas.so is a fortran library and libcblas.so is for C.

All in all, good job.  Thanks.

Xiao-Yong
-- 
c/*__o/*
<\ * (__
*/\  <
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Patrick Perry's BLAS package

[Patrick Perry]

Wow, thanks for noticing, Alberto!  For anyone interested, I put up a  
formal announcement describing the bindings a little bit here:


http://quantile95.com/

I just registered the domain yesterday, so it may take a few days to  
resolve the DNS magic.  Here's the text of the announcement:


I’m really happy that people seem to be interested in the library.  
Alberto, in particular, is the primary author of hmatrix, another  
haskell linear algebra library (which I stole a few ideas from), so if  
he endorses it, that means a lot to me.


So, Yet Another Linear Algebra Library? I’ve already mentioned  
hmatrix. There’s also another one called HBlas. Why would anyone want  
a third? Here are my reasons:


	* Support for both immutable and mutable types. Haskell tries to make  
you use immutable types as much as possible, and indeed there is a  
very good reason for this, but sometimes you have a 100MB matrix, and  
it just isn’t very practical to make a copy of it every time you  
modify it. hmatrix only supports immutable types, and HBlas only  
supports mutable ones. I wanted both.
	* Access control via phantom types. When you have immutable and  
mutable types, it’s very annoying to have separate functions for each  
type. Do I want to have to call “numCols” for immutable matrices and  
“getNumCols” for mutable ones, even though both functions are pure,  
and both do exactly the same thing? No. If I want to add an immutable  
matrix to a mutable one, to I want to first call “unsafeThaw” on the  
immutable one to cast it to be mutable? No. With the phantom type  
trick, you can get around this insanity. Jane Street Capital has a  
very good description of how this works.
	* Phantom types for matrix and vector shapes. This is a trick I  
learned from darcs. It means that the compiler can catch many  
dimension-mismatch mistakes. So, for instance, a function like

foo :: (BLAS1 e) =>
Matrix (m,n) e -> Matrix (n,k) e -> Int -> Vector m e
foo a b i = let x = row b i in a <*> x
will not type-check. (”<*>” is the function to multiply a matrix by a  
vector. Everything is ok if you replace “row” by “col”.) This feature  
has caught a few bugs in my code.


	* Taking the conjugate transpose (”herm”) of a matrix is an O(1)  
operation. This is similar to hmatrix, where taking the transpose is  
O(1). As BLAS and LAPACK (mostly) support this, it makes no sense to  
copy a matrix just to work with the conjugate transpose. Why conjugate  
transpose instead of just transpose? Because the former is a far more  
common operation. This is why the “‘” operator in MATLAB is conjugate  
transpose. The drawback for this feature is that BLAS and LAPACK do  
not support it everywhere. In particular, QR decomposition with  
pivoting is going to be a huge pain in the ass to support for herm-ed  
matrices.
	* Support for triangular and hermitian views of matrices. This is a  
feature of BLAS that no one seems to support (not even MATLAB). In  
addition to the “Matrix” type, there are “Tri Matrix” and “Herm  
Matrix” types that only refer to the upper- or lower-triangular part  
of the matrix.
Hopefully the features above are compelling enough to make people want  
to use the library. These bindings have been a lot of work. For me to  
come up with the feature list above, I’ve already gone through a few  
iterations of dramatic re-writes (hence the version number). Of  
course, I always welcome suggestions for how to make it better.


What’s next? In the immediate future, I plan to add banded matrices.  
I’ve already written a good chunk of code for this, but it isn’t very  
well tested, so I decided to leave it out of the release. I’m also  
going to add permutation matrices. I don’t have plans to add support  
for packed triangular matrices, but if someone else wanted to do that,  
I would be happy to include it. The same goes for symmetric complex  
matrices.


LAPACK support is on the horizon, but that may take awhile. Also, I  
probably won’t do more than SVD, QR, and Cholesky, since those are all  
I need. Expect a preliminary announcement by the end of the summer.


This work would not have been possible without looking at the other  
excellent linear algebra libraries out there. In particular the GNU  
Scientific Library was the basis for much of the design. I also drew  
inspiration from hmatrix and the haskell array libraries.


Please let me know if you have any success in using the library, and  
if you have any suggestions for how to make it better.



Patrick

On Jun 6, 2008, at 5:36 AM, Alberto Ruiz wrote:


Hello all,

I have just noticed that yesterday this fantastic package has been  
uploaded to hackage:


http://hackage.haskell.org/cgi-bin/hackage-scripts/package/blas-0.4

We finally have a high quality library for numeric linear algebra.  
This is very good news for the Haskell community.


Patrick, many thanks for your excellent work. Do you have similar  
plans for LAPACK?


Alberto


_

[Haskell-cafe] ANNOUNCE: Cabal-1.4 release candidate

[Duncan Coutts]

Hi everyone,

== Cabal-1.4 release candidate ==

The second release candidate of Cabal-1.4 is out:
http://haskell.org/cabal/download.html

Please test and report bugs:
http://hackage.haskell.org/trac/hackage/

The aim for the Cabal-1.4 release is to get various fixes and
improvements into the hands of developers and to support a release of
cabal-install.

== cabal-install ==

A snapshot of cabal-install is also available:
http://haskell.org/cabal/download.html

It requires the zlib and HTTP packages (both are available from
hackage). Bug reports should go in the same trac as above.

cabal-install is intended to be the standard command line interface to
the whole Cabal/Hackage system. It replaces the "runhaskell Setup.hs"
interface and a few other tools you may or may not have heard of
(cabal-setup, cabal-upload, cabal-get). cabal-install is usable now and
we will be making a proper release some time after the Cabal-1.4
release.

== Testing ==

We are particularly interested in finding regressions from Cabal-1.2.x
or any important fixes that will require API changes since once we
release 1.4 we have to maintain API compatibility for the rest of the
1.4.x series.

This is also an excellent opportunity to make sure your favourite bug or
feature request is properly described in our bug tracker:
http://hackage.haskell.org/trac/hackage/

To help us guide development priorities please add yourself to the
ticket's cc list and describe why that bug or feature is important to
you.

== Compatibility ==

We have tried to preserve compatibility with all packages that worked
with the Cabal-1.2.x series. That is, packages that can be built using
Cabal (including custom Setup.hs scripts) but not packages that directly
import and use the Cabal API. Packages that directly import and use the
Cabal api will need updating. This affects packages that build distro
packages for example, rpm debs etc.

Currently we know of only one package on hackage which has a Setup.hs
script that compiles with 1.2 but fail to compile with 1.4. Takusen,
will require an update to be able to work with both Cabal-1.2.x and
1.4.x. A patch has been sent to the maintainers of Takusen.

== Credits ==

On behalf of the Cabal hackers and the community generally I'd like to
thank the large number of people who have contributed patches during
this development series. Previously I was rather worried that we were
not getting enough contributors to fix bugs and do new feature
development, but now I'm very pleased. :-)

== Get involved ==

Of course there's still a lot to do! We have big plans for Cabal-2.0,
cabal-install and the Hackage website. So if you're interested in
helping out with this core infrastructure project then:

 * subscribe to the cabal-devel mailing list:
 http://www.haskell.org/mailman/listinfo/cabal-devel

 * grab the source:
 http://haskell.org/cabal/code.html

 * read the guide to the source code:
 http://hackage.haskell.org/trac/hackage/wiki/SourceGuide

 * take a look at our list of bugs and feature requests:
 http://hackage.haskell.org/trac/hackage/report/12
   especially the easy tickets:
 http://hackage.haskell.org/trac/hackage/report/13

Duncan
(wearing his Cabal release manager hat)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Design your modules for qualified import

[Henning Thielemann]

On Fri, 6 Jun 2008, Achim Schneider wrote:

> Jan-Willem Maessen <[EMAIL PROTECTED]> wrote:
>
> > There's one caveat: Always choose descriptive names, even if you are
> > assuming that you will usually use a qualified import.  The
> > following are wonderful names, even though they conflict with the
> > prelude: null
> >filter
> >map
> >lookup
> >
> import Prelude as P
>
> > The following are terrible names:
> >T
> >C
>
> Not to mention that this usage is hideously confusing while looking at
> the haddock docs.

But that will be resolved when Haddock can show identifiers with
qualifications.

> While I don't mind Haskore having them, they should just be different
> names for a type that has a clear name. It also appears to generate an
> excessive amount of modules.

It's good to have fine grained modules, because you can more easily
exchange the parts you want different from the standard way. For reducing
import lists for simple songs I think we could provide wrapper modules.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Design your modules for qualified import

[Achim Schneider]

Jan-Willem Maessen <[EMAIL PROTECTED]> wrote:

> On Jun 6, 2008, at 8:12 AM, Wolfgang Jeltsch wrote:
> 
> > Am Donnerstag, 5. Juni 2008 17:19 schrieb Johan Tibell:
> >> […]
> >
> >> 2. It's the default. You have to add "qualified" to all your
> >> imports to make them qualified. In most language imports are
> >> qualified by default. I think the latter would have been a better
> >> choice but we have to live with the current design so bite the
> >> bullet and add those qualified keywords to your imports.
> >
> > If you leave out “qualified”, you still get the qualified names  
> > imported.  And
> > if you use conflicting identifiers always qualified then there’s
> > no problem.
> > For example, you can use
> >
> >import Data.Set as Set
> >import Data.List as List
> >
> > and then just say Set.null or List.null.
> 
> There's one caveat: Always choose descriptive names, even if you are  
> assuming that you will usually use a qualified import.  The
> following are wonderful names, even though they conflict with the
> prelude: null
>filter
>map
>lookup
> 
import Prelude as P

> The following are terrible names:
>T
>C
> 
Not to mention that this usage is hideously confusing while looking at
the haddock docs. While I don't mind Haskore having them, they should
just be different names for a type that has a clear name. It also
appears to generate an excessive amount of modules.

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Design your modules for qualified import

[Jan-Willem Maessen]

On Jun 6, 2008, at 8:12 AM, Wolfgang Jeltsch wrote:


Am Donnerstag, 5. Juni 2008 17:19 schrieb Johan Tibell:

[…]



2. It's the default. You have to add "qualified" to all your imports
to make them qualified. In most language imports are qualified by
default. I think the latter would have been a better choice but we
have to live with the current design so bite the bullet and add those
qualified keywords to your imports.


If you leave out “qualified”, you still get the qualified names  
imported.  And
if you use conflicting identifiers always qualified then there’s no  
problem.

For example, you can use

   import Data.Set as Set
   import Data.List as List

and then just say Set.null or List.null.


There's one caveat: Always choose descriptive names, even if you are  
assuming that you will usually use a qualified import.  The following  
are wonderful names, even though they conflict with the prelude:

  null
  filter
  map
  lookup

The following are terrible names:
  T
  C

What's a T?  What's a C?  There's no excuse to give something a lousy  
name just because the enclosing module is descriptively named.  I  
reject the naming conventions used by ML modules when writing Haskell  
code: Haskell modules are not ML modules.


-Jan-Willem Maessen

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Patrick Perry's BLAS package

[Alberto Ruiz]

Hello all,

I have just noticed that yesterday this fantastic package has been 
uploaded to hackage:


http://hackage.haskell.org/cgi-bin/hackage-scripts/package/blas-0.4

We finally have a high quality library for numeric linear algebra. This 
is very good news for the Haskell community.


Patrick, many thanks for your excellent work. Do you have similar plans 
for LAPACK?


Alberto
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Design your modules for qualified import

[Wolfgang Jeltsch]

Am Donnerstag, 5. Juni 2008 17:19 schrieb Johan Tibell:
> […]

> 2. It's the default. You have to add "qualified" to all your imports
> to make them qualified. In most language imports are qualified by
> default. I think the latter would have been a better choice but we
> have to live with the current design so bite the bullet and add those
> qualified keywords to your imports.

If you leave out “qualified”, you still get the qualified names imported.  And 
if you use conflicting identifiers always qualified then there’s no problem.  
For example, you can use

import Data.Set as Set
import Data.List as List

and then just say Set.null or List.null.

> […]

> * Summary
>
> Whenever you write a library design it so it works well with qualified
> imports. That means leaving namespacing issues to the module system.
> Try to think of how code using your functions will look like if it
> uses them qualified.

I totally agree.

> […]

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] example of FFI FunPtr

[Galchin, Vasili]

Hi Claude,

 I want to do an incremental "experiment". I want just want  to pass a C
function to "callback" to a Haskell function. ???

Thanks, Vasili

On Thu, Jun 5, 2008 at 4:21 AM, Claude Heiland-Allen <
[EMAIL PROTECTED]> wrote:

> Galchin, Vasili wrote:
>
>> Hello,
>>
>>   I want to model a Haskell function that is a callback from C. I have
>> only found one example in the unix package's Semaphore.hsc, which
>> apparently
>> is not used. I want to be able to marshall a Haskell function that is a
>> first class citizen residing in a Haskell data type and pass to a C
>> function
>> via FFI. Are there examples of this?
>>
>
> Attached is a simple example.
>
> The main thing to note is 'foreign import ccall "wrapper"' which gives you
> a factory for turning Haskell functions into foreign function pointers.
>
> More information:
>
> http://www.cse.unsw.edu.au/~chak/haskell/ffi/
>
>
> Claude
> --
> http://claudiusmaximus.goto10.org
>
>
> CallBacker: CallBacker.hs callerback.c callerback.h
>ghc -O2 -Wall -fffi -o CallBacker CallBacker.hs callerback.c
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe