May 2010 - Haskell-Cafe

Numerical Analysis
by Pierre-Etienne Meunier 19 May '10

19 May '10

Hello Cafe, Being a complete beginner in the field of numerical analysis, but anyway needing it to solve "real problems", I wrote a few functions recently to solve systems of polynomial equations using the "projected polyhedron" method by Maekawa and Patrikakalis. This requires solving systems of linear equations precisely, thus the simple Gauss method was not enough, and I had to write also an algorithm for the "SVD decomposition". Upon discovering the algol / fortran specifications of these :-( , heavily published in important journals, I thought it would be nice to provide the world with fast reliable implementation of these numerical methods (i.e. not simply bindings to lapack). Moreover, writing numerical things in haskell is much more pleasant than I thought at first. Here are a few random thoughts on this : - The haskell 98 norm does not require enough about IEEE-754 compliance, thus C bindings are still needed to guess for instance the machine epsilons, or manipulating ULPs. Moreover, taking advantage of hardware rounding is not easy, even if the hardware is IEEE-compliant : calling a C function from haskell screws up the speed advantages of hardware rounding, for instance. Maybe the new LLVM backend will make this possible ? - The current Array library is definitely not adapted to production code. It makes debugging tricky, requires a heavy use of Debug.Trace to actually see what happens, and does not seem as fast as one could expect. It seems that each algebra library on hackage redefines part of it, but a unified version would be nice : a discussion within the haskell community seems to be needed... - A numerical analysis library should really take advantage of the parallelism in GHC, especially with the arrival of hardware such as fermi (anyway, I do not know how much haskell is compilable to fermi code). The love for loops and side-effects among this community is hard to understand, but that's more of a cultural problem. Finally, as stated by William Stein, the creator of SAGE, of course it would take thousands of man-years to rewrite these codes in python, but if a language like haskell, and a compiler do 90% of the work, how many man-years are left ? If anyone here has got the time, the team and the will to start such a project, I'd love to contribute ! Cheers, PE

7 13

Re: [Haskell-cafe] Bug with [Double]
by Dmitry Olshansky 19 May '10

19 May '10

But Prelude Data.List> [1,1+2/3..4] :: [Double] [1.0,1.6666666666666665,2.333333333333333,2.9999999999999996,3.666666666666666,4.333333333333332] Prelude Data.List> unfoldr (\n -> let n'=n+2/3 in if n' <= 4 then Just (n',n') else Nothing) 1 :: [Double] [1.6666666666666665,2.333333333333333,2.9999999999999996,3.666666666666666] Prelude Data.List> takeWhile (<=4) $ iterate (+2/3) 1 :: [Double] [1.0,1.6666666666666665,2.333333333333333,2.9999999999999996,3.666666666666666] How 'dodgy' it should be to produce different result? How [a,b..c] works in this case? > > > 2010/5/19 Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com>: >> Dmitry Olshansky <olshanskydr(a)gmail.com> writes: >> >>> Hello all, >>> >>> It seems that I saw something like this in Cafe recevtly. But I am not sure... >>> In GHC 6.12.1 (Platform 2010 on Windows Vista) I have >>> >>> Prelude> [1,1+2/3..10] >>> [1.0,1.6666666666666665,2.333333333333333,2.9999999999999996,3.666666666666666,4.333333333333332,4.999999999999998,5.666666666666664,6.33333333333333,6.9999999999999964,7.6666666666666625,8.333333333333329,8.999999999999995,9.66666666666666,10.333333333333327] >>> >>> -- It is a bug! >> >> No it isn't, because of the dodgy Ord instance for Float and Double values. >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic(a)gmail.com >> IvanMiljenovic.wordpress.com >> >

1 0

Type famillies & Lifting IO
by Maciej Piechotka 19 May '10

19 May '10

I started playing with type families. I wanted to achieve, for the beginning, something like: > import qualified Control.Monad.IO.Class as IOC > import Control.Monad.Trans.Class > import Control.Monad.Trans.Cont > import Data.Functor.Identity > class (Monad m, Monad (IO' m)) => MonadIO m where > type IO' m :: * -> * > liftIO :: IO a -> IO' m a > liftM :: m a -> IO' m a It allows to add IO to computation even if computation originally was 'pure'. First step was easy: > instance MonadIO Identity where > type IO' Identity = IO > liftIO = id > liftM = return . runIdentity > > instance MonadIO IO where > type IO' IO = IO > liftIO = id > liftM = id > > instance MonadIO (ST r) where > type IO' (ST r) = IO > liftIO = id > liftM = unsafeSTToIO > > --instance IOC.MonadIO m => MonadIO m where > --type IO' m = m > --liftIO = IOC.liftIO > --liftM = id However I run into problems - this code doesn't want to compile: > instance MonadIO m => MonadIO (ContT r m) where > type IO' (ContT r m) = ContT r (IO' m) > liftIO f = ContT $ \cont -> liftIO f >>= cont > liftM f = ContT $ \cont -> liftM f >>= cont Or this: > instance MonadIO m => MonadIO (ContT r m) where > type IO' (ContT r m) = ContT r (IO' m) > liftIO f = lift . liftIO > liftM f = lift . liftIO In fact there is strange interfering types of ghci: ghci> :t lift . liftIO lift . liftIO :: (m ~ IO' m1, MonadTrans t, Monad m, MonadIO m1) => IO a -> t m a ghci> :t lift . liftIO :: (m ~ IO' m1, MonadTrans t, Monad m, MonadIO m1) => IO a -> t m a <interactive>:1:7: Couldn't match expected type `IO' m' against inferred type `m1' `m1' is a rigid type variable bound by an expression type signature at <interactive>:1:18 NB: `IO'' is a type function, and may not be injective In the second argument of `(.)', namely `liftIO' In the expression: lift . liftIO :: (m ~ (IO' m1), MonadTrans t, Monad m, MonadIO m1) => IO a -> t m a What's the problem? I guess I don't understand something basic about type famillies. Regards

1 0

What do _you_ want to see in FGL?
by Ivan Lazar Miljenovic 19 May '10

19 May '10

Since I've volunteered myself to help maintain/upgrade FGL, what do the people in the community want to see happen with it? Here are some ideas that I have regarding FGL: * I had already started working on a new generic graph class [1] (with initial draft at [2]) to act as a wrapper around FGL and other graph implementations. However, if I'm going to be updating FGL anyway I might as well combine the two and generalise/update FGL instead. Generally speaking, this will involve the following items: - Splitting and expanding the typeclasses involved; most class methods would have default definitions but this will allow people to override the defaults if there's a more efficient way for their datatype. - Having a separate parameter (using associated types?) for the node type rather than just using Int. - Providing more "fundamental" graph operations that may be of use. However, the downside of this is that datatypes such as Data.Graph in containers won't match this anymore due to the lack of node and edge labels. I think this fair price to pay, especially if the mapping aspects are split off into another typeclass. [1]: http://www.haskell.org/pipermail/haskell-cafe/2009-June/063402.html [2]: http://code.haskell.org/~ivanm/Graph.hs * Better fundamental data structures: one of the things that has always annoyed me about FGL is how much it uses tuples; I propose re-defining the Context type to be a record-based data structure. Also, usage of Sets, Maps, etc. where applicable. * Proper instances: make graphs instantiate Eq, Ord, Show and Read (where read . show == id). The Show and Read instances will probably usually be like how Data.Map has them, so helper functions can be defined to help out with this. * Split off the instances: maybe keep one basic graph datatype in FGL, but then have separate packages for others (which means its easier to add new datatypes without needing a new release, etc.). * Split off the various Data.Graph.Inductive.Query functions/algorithms, and merge in the ones I have defined in Graphalyze [3]. [3]: http://hackage.haskell.org/package/Graphalyze * Scrap Data.Graph.Inductive.Graphviz and recommend usage of my graphviz library [4] instead. [4]: http://hackage.haskell.org/package/graphviz * Data.Graph.Inductive.Monad: does anyone actually use this? * Benchmarks and tests. What do other people think? Any other suggestions? Also, once I release the next version of graphviz (hopefully later today), I was going to work on improving SourceGraph [5] by providing command line options, etc. to it; would people prefer I work on FGL instead? [5]: http://hackage.haskell.org/package/SourceGraph -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

9 48

GADTs and Scrap your Boilerplate
by Oscar Finnsson 18 May '10

18 May '10

Hi, I'm writing a XML (de)serializer using Text.XML.Light and Scrap your Boilerplate (a thttp://github.com/finnsson/Text.XML.Generic) and so far I got working code for "normal" ADTs but I'm stuck at deserializing GADTs. I got the GADT data DataBox where DataBox :: (Show d, Eq d, Data d) => d -> DataBox and I'm trying to get this to compile instance Data DataBox where gfoldl k z (DataBox d) = z DataBox `k` d gunfold k z c = k (z DataBox) -- not OK toConstr (DataBox d) = toConstr d dataTypeOf (DataBox d) = dataTypeOf d but I can't figure out how to implement gunfold for DataBox. The error message is Text/XML/Generic.hs:274:23: Ambiguous type variable `b' in the constraints: `Eq b' arising from a use of `DataBox' at Text/XML/Generic.hs:274:23-29 `Show b' arising from a use of `DataBox' at Text/XML/Generic.hs:274:23-29 `Data b' arising from a use of `k' at Text/XML/Generic.hs:274:18-30 Probable fix: add a type signature that fixes these type variable(s) It's complaining about not being able to figure out the data type of b. I'm also trying to implement dataCast1 and dataCast2 but I think I can live without them (i.e. an incorrect implementation). I guess my questions are: 1. Is it possible to combine GADTs with Scrap your Boilerplate? 2. If so: how do you implement gunfold for a GADT? -- Oscar

6 7

Help with Bird problem 1.4.1
by R J 18 May '10

18 May '10

Newbie trying to get through Bird. Could someone provide a clean solution, with proof (so I can see how these proofs are laid out), to this: Given: f :: Integer -> Integerg :: Integer -> (Integer -> Integer) h :: ...h x y = f (g x y) Questions: a. Fill in the type assignment for "h". b. Which of the following is true: (i) h = f . g (ii) h x = f . (g x) (iii) h x y = f . (g x y) _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

2 1

Wait forever in main thread
by DPX-Infinity 18 May '10

18 May '10

Hi, I'm writing a program which listens to some D-Bus signals using DBus.Client.onSignal function from dbus-client package. This function runs IO action in separate haskell thread when signal is received. My program does nothing except signal handling, so after setting up signals it has to wait indefinitely. Now I'm using not very clean (I think so) forever $ threadDelay 10000000 . Is there another (I mean, correct) method to do this thing?

6 10

executeFile failing on macosx
by David Powell 18 May '10

18 May '10

"executeFile" is failing for me on Mac OS X 10.5.8, with ghc 6.12.1 when compiling with "-threaded". Compiling without -threaded, or running on linux is fine. When compiled with -threaded, the following snippet produces the error: testProg: /bin/echo: executeFile: failed (Operation not supported) > import System.Posix.Process > main = do > > forkProcess $ executeFile "/bin/echo" False ["Ok"] Nothing Any suggestions for a work around for this would be appreciated. Cheers, -- David Powell

4 5

Windows 7 Permission Denied Problem on Cabal
by Ralph Hodgson 17 May '10

17 May '10

Following a successful install of the Haskell Platform on MAC OSX, I proceed to update my Windows PC. Frustration followed. I am blocked by a "Permission Denied" error when I do a "Setup install": >ghc --make Setup [58 of 58] Compiling Main ( Setup.hs, Setup.o ) Linking Setup.exe ... >Setup configure Configuring Cabal-1.8.0.4... >Setup build Preprocessing library Cabal-1.8.0.4... Building Cabal-1.8.0.4... Registering Cabal-1.8.0.4... >Setup install Setup: permission denied > I changed the permission on folders in the "Haskell Platform" directories to "full control", without any effect. I have searched the web for help but could not find my problem. Can't help but think it is something trivial but what? Help appreciated. Ralph Hodgson, @ralphtq <http://twitter.com/ralphtq>

4 6

GHC Install button grayed out
by David Matuszek 17 May '10

17 May '10

I'm trying to install Haskell Platform 2010.1.0.1 on my Mac, downloaded from http://hackage.haskell.org/platform/ I have: Mac OS X 10.6.3 2 x 2.66 GHz Dual-Core Intel Xeon XCode 3.1.3 Also, I am an admin on this machine. When I try to install GHC-6.12.1-i386.pkg, I agree to the license, the installer skips over Destination Select, and brings me to the Standard Install page, with the Install button grayed out. It remains grayed out for several minutes (and presumably forever). I subsequently tried the 2009 platform, with the same results. Any idea what the problem might be? Thanks, Dave Matuszek PS. I really dislike MacPorts, so please don't suggest that.

2 1