- Haskell-Cafe - Haskell.org

ANN: incremental-sat-solver
by Sebastian Fischer 29 Jan '09

29 Jan '09

Simple, Incremental SAT Solving as a Library ============================================ This Haskell library provides an implementation of the Davis-Putnam- Logemann-Loveland algorithm (cf. <http://en.wikipedia.org/wiki/DPLL_algorithm >) for the boolean satisfiability problem. It not only allows to solve boolean formulas in one go but also to add constraints and query bindings of variables incrementally. The implementation is not sophisticated at all but uses the basic DPLL algorithm with unit propagation. The package is available at: <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/incremental-sat-… > Unlike 'sat' and 'sat-micro-hs' it is a library, and unlike 'libsat' it provides an interface for incremental solving. On the other hand, the implementation is much simpler (and probably less efficient) than 'libsat's. You are invited to improve on that, if you like. The code is on github: <http://github.com/sebfisch/incremental-sat-solver> Cheers, Sebastian

2 2

ANN: convertible (first release)
by John Goerzen 29 Jan '09

29 Jan '09

Hi folks, I have uploaded a new package to Haskell: convertible. At its heart, it's a very simple typeclass that's designed to enable a reasonable default conversion between two different types without having to remember a bunch of functions. The return type from this conversion is "Either ConvertError a", and conversions are expected to do sanity checking (such as bounds checking when converting to types like Int), so as to produce neither garbage nor exceptions as part of the conversion process. The package also includes instances of the Convertible typeclass for working with numeric types as well as dates and times. Notably, it has code to convert between System.Time types and their Data.Time siblings, and vice versa, a capability I found annoyingly lacking in the standard library. There is also a simple wrapper function called convert, that transforms a Left result into a call to error, and returns a Right result. For HDBC v2.0, the SqlValue/SqlType system has been completely rewritten in terms of Convertible, though I expect backwards compatibility will not be broken by this change (existing code will compile and run fine). I hope to release v2.0 of the HDBC API and backends in a few days. Convertible is not for everyone; if you care whether you use truncate or round to convert a Double to an Integer, this isn't for you. Note, though, that you can import the library without its default instances, so you can define your own if you prefer. API docs and downloads at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/convertible -- John

5 10

HDBC-ODBC, bindCol
by G?uenther Schmidt 29 Jan '09

29 Jan '09

Hi John, I've just been going through the HDBC-ODBC code wondering if I could find the spot that needs changing so that Doubles work properly with MS-Access. Could you please tell me, if I understand this correctly? The bindCol function does not actually look at the particular value type, ie. SqlDouble, SqlInteger ..., to determine the type but queries the database via sqlDescribeParam to get the type. Which might fail though and not leave a clue. In that case the SqlType still isn't used, but rather some default? If I was more literate in Haskell I would propably be able to answer this myself, sry, I'll catch up. And I had a hell of a time finding an SQL/ODBC for C Tutorial and never coded in C. Thanks upfront Günther

2 1

Bugs in Hugs
by wren ng thornton 29 Jan '09

29 Jan '09

In testing some of my packages against Hugs, I've uncovered bugs[1]. Unfortunately the bug tracker at: http://hackage.haskell.org/trac/hugs/newticket?type=defect doesn't seem to allow normal users to submit tickets. Does anyone know how to submit bug reports to Hugs these days? [1] Namely, the Prelude.isNaN and Prelude.isInfinite functions don't work: Hugs> (0/0::Float) nan Hugs> isNaN (0/0::Float) False Hugs> (0/0::Double) nan Hugs> isNaN (0/0::Double) False Hugs> (1/0::Float) inf Hugs> isInfinite (1/0::Float) False Hugs> (1/0::Double) inf Hugs> isInfinite (1/0::Double) False -- Live well, ~wren

2 1

Re: Why binding to existing widget toolkits doesn't make any sense
by John Lato 28 Jan '09

28 Jan '09

Achim Schneider wrote: > > So what's left of those TK's if we don't use their abstractions and > replace them with Haskell? Drawing and layouting, that's what's > left[3]. Both, IMNSHO, do not justify carrying around bloaty external > dependencies, they're too trivial. They certainly don't justify using > unsafePerformIO to hide foreign side effects and the headaches > associated with it. > > > So, if you don't mind, I'm going to stop trying to fit cubes into > round holes and gonna use reactive and fieldtrip[4] to do things. > Does this mean you're volunteering to create a fieldtrip-based toolkit with widgets and layout? John Lato

2 1

GHC's -fwarn-unused-imports ignores function signatures
by Michael Snoyman 28 Jan '09

28 Jan '09

I was writing code similar to the following and compiling with "-Wall -Werror." Clearly I *am* using Data.ByteString for the function signatures. {-# OPTIONS_GHC -fwarn-unused-imports -Werror #-} import qualified Data.ByteString as B import qualified Data.ByteString.UTF8 as BU toString :: B.ByteString -> String toString = BU.toString fromString :: String -> B.ByteString fromString = BU.fromString main :: IO () main = putStrLn $ toString $ fromString "Hello World!" The warning I get is: Unused.hs:2:0: Warning: Module `Data.ByteString' is imported, but nothing from it is used, except perhaps instances visible in `Data.ByteString' To suppress this warning, use: import Data.ByteString() Am I doing something wrong or is this a bug in GHC? Thanks, Michael

3 2

Re: [Haskell-cafe] hmatrix, Windows and GCC
by Patrick Perry 28 Jan '09

28 Jan '09

> Well, I guess I am not the only one! > > This blog show exactly what I am looking for! > > http://quantile95.com/2008/10/31/ann-blas-bindings-for-haskell-version-06/ If you're looking to implement other linear algebra algorithms in Haskell, there's enough at http://github.com/patperry/lapack to implement a QR decomposition with column pivoting with fairly minimal effort. Householder reflections and permutation matrices are already supported. You will also need the latest BLAS bindings, also available at github. Note that these libraries are not compatible with hmatrix. What would *really* be awesome would be an implementation of an SVD algorithm: take a bidiagonal matrix and produce a (lazy) list of Givens rotations that diagonalizes the matrix. That would probably be a 2-4 week project, but would be really useful. Take a look at the code and references at http://netlib.org/lapack/explore-html/zbdsqr.f.html if you're interested. The LAPACK version, zbdsqr, takes "B" and factors it as "B = Q S P^H". Optionally, it sets U := U Q VT := P^H VT C := Q^H C Annoyingly, there is no way to specify an input matrix "D" and set "D := D P". It'd be really cool to have a Haskell function of type svdBidiagonal :: (WriteBanded a m) => a (n,p) e -> m [(Givens,Givens)] The type signature means that "a" is a mutable banded matrix of shape "(n,p)" with elements of type "e" that can be modified in monad "m". I'm envisioning that the result is a lazy list, "gs", and that no computation gets done until the "gs" list is traversed. So, if someone just wants singular values, then they would do "liftM length . svdBidiagonal". If they want to update "U := U Q", then they would do something like: mapM_ (applyGivens u) $ liftM (fst . unzip) $ svdDidiagonal a The user has the option to update as many matrices they want in whatever way they want. This is only possible with laziness. It is a perfect example of the "glue" John Hughes talks about in "Why Functional Programming Matters". Patrick > > On Wed, Jan 28, 2009 at 08:21, Rafael Gustavo da Cunha Pereira Pinto < > RafaelGCPP.Linux at gmail.com> wrote: > > > I was planning to recompile everything (ATLAS, LAPACK and GHC > included) > > this weekend, so I can have a similar environment on Windows and > Linux... > > Having to "borrow" libraries > > > > Since I am married, this means it will actually happen on some > weekend till > > 2010. > > > > > > What I really would like to try is a (purely?) functional approach > to > > create a (P)LU decomposition of a matrix. I am not too much > worried (at > > first) with performance or memory constraints, since I only want > to see how > > beautiful it gets (or not!). (This one might happen somewhere in > this > > century...) > > > > > > Thanks anyway > > > > > > > > On Wed, Jan 28, 2009 at 07:57, allan <a.d.clark at ed.ac.uk> wrote: > > > >> Hi > >> > >> The INSTALL file in the hmatrix repository has some very clear > >> instructions for installation on Windows. > >> http://perception.inf.um.es/~aruiz/darcs/hmatrix/INSTALL<http://perception.inf.um.es/%7Earuiz/darcs/hmatrix/INSTALL > > > >> > >> However note this section at the bottom: > >> "Unfortunately the lapack dll supplied by the R system does not > include > >> zgels_, zgelss_, and zgees_, so the functions depending on them > >> (linearSolveLS, linearSolveSVD, and schur for complex data) > >> will produce a "non supported in this OS" runtime error." > >> > >> Of course linearSolve is exactly what you will be wanting so this > won't > >> work for you. > >> I ran into exactly this problem myself. I actually didn't get as > far as a > >> run-time error as I got a linker error. > >> > >> I don't have any solution for you though, sorry. > >> > >> regards > >> allan > >> > >> > >> > >> > >> Rafael Gustavo da Cunha Pereira Pinto wrote: > >> > >>> > >>> > >>> Hi all, > >>> > >>> I am writing a program that uses hmatrix for solving some linear > systems. > >>> The hmatrix package depends on BLAS, which, in turn, depend on > GCC 4.2 to be > >>> built (at least ATLAS does). > >>> > >>> GHC 6.10 for Windows is pre-packaged with GCC 3.4.5, and it > leaves me > >>> with the impression that I would have incompatible ABIs. > >>> > >>> My questions: > >>> > >>> 1) Why GHC 6.10 still uses GCC 3.4.5 in Windows? I know mingw > considers > >>> GCC 4.2 to be alpha, but, lets face it, 4.2 is almost obsolete! > >>> 2) Is it possible to rebuild GHC 6.10, using Windows and GCC > 4.2? Is > >>> there any guide for doing this? > >>> 3) Has any of you tried hmatrix on Windows? How did you do it? > >>> > >>> Thanks, > >>> > >>> Rafael > >>> > >>> -- > >>> Rafael Gustavo da Cunha Pereira Pinto > >>> Electronic Engineer, MSc. > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >> > >> > >> > >> -- > >> The University of Edinburgh is a charitable body, registered in > >> Scotland, with registration number SC005336. > >> > >> > > > > > > -- > > Rafael Gustavo da Cunha Pereira Pinto > > Electronic Engineer, MSc. > > > > > > -- > Rafael Gustavo da Cunha Pereira Pinto > Electronic Engineer, MSc. >

1 0

Problems running vectorised dph program
by Fabian Reck 28 Jan '09

28 Jan '09

Hi, I've just begun to play with Data Parallel Haskell but instantly ran into a problem. My very stupid but very simple example ought to sum the values of all Nodes in a Tree. The non-vectorised code behaves like I expected, the vectorised code doesn't terminate. I compiled and ran it the same way as the example in the tutorial: ghc -c -O -fdph-par Main.hs ghc -c -Odph -fcpr-off -fdph-par MinimalParTree.hs ghc -o MinimalParTree -fdph-par -threaded MinimalParTree.o Main.o ./MinimalParTree My question is: Is this a bug or is something wrong with the program? Thanks Fabian -------------------------------------------------------------------- module Main where import MinimalParTree main = do print $ sumTreeWrapper 20 -------------------------------------------------------------------- {-# LANGUAGE PArr, ParallelListComp #-} {-# OPTIONS -fvectorise #-} module MinimalParTree (sumTreeWrapper) where import qualified Prelude import Data.Array.Parallel.Prelude import Data.Array.Parallel.Prelude.Int data Tree a = Node a [: Tree a :] testTree :: Int -> Tree Int testTree elem = Node elem emptyP sumTree :: Tree Int -> Int sumTree (Node x ns) = x + sumP (mapP sumTree ns) {-# NOINLINE sumTreeWrapper #-} sumTreeWrapper :: Int -> Int sumTreeWrapper elem = sumTree (testTree elem) --------------------------------------------------------------------

2 2

Haskell Web Frameworks
by John A. De Goes 28 Jan '09

28 Jan '09

On Jan 27, 2009, at 1:05 PM, Michaeljohn Clement wrote: > +1 > > This is the conclusion I have come to in building collaborative > Web applications. > > I agree that there seems to be a gap here in the Haskell Web > frameworks people are building. Yes. It's a dead end and it seems a shame to waste effort on it. > I do not believe compiling Haskell to ECMAScript/JavaScript is a > productive avenue. There is too much pain in trying to abstract > away the JavaScript model only to write everything in Haskell and > end up with worse performance as a reward. I believe GWT, among other projects, has shown that you can create faster executing JavaScript by compiling from a statically-typed language than you can by hand-coding JavaScript (for one, you can do a multitude of inlining and simplification transformations that are not easy in a dynamic language). There is much room for research and development, of course, especially in the context of functional languages. > There is very little wrong with ECMAScript if people would only > learn it properly and play to its strengths instead of trying to > turn it into things it is not. I like JavaScript, and I love ECMAScript 4 (which unfortunately won't see the light of day), but they are not functional languages. And for the foreseeable future, there is one and exactly one scripting language for the browser, and anyone who wants to use a different language will have to do so by compiling to JavaScript. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101

1 0

Changing type of 'when'
by Maurício 28 Jan '09

28 Jan '09

Hi, Sugestion: 'when' in Control.Monad is typed as :: Bool -> IO () -> IO (). Why not type it as: :: forall a. => Bool -> IO a -> IO () ? It is easy for 'when' to ignore the result of the first computation, and this would not break existing code, and also save a lot of >> return ()s. Best, Mauríco

3 3