- Glasgow-haskell-users

specializations on float
by Hal Daume III 08 Aug '02

08 Aug '02

the ghc docs suggest using Doubles instead of Floats because GHC specializes Double but not float...I want to use floats to save memory and to test this claim, i grepped through the libraries for the SPECIALIZE keyword and find that with the exception of a few complex routines (which I don't care about), floats are just as specialized as doubles...is this the case, or am I missing something? the results of grepping are: moussor:libraries/ grep "SPECIALI[SZ]E" `find . | grep 'hs$'` | cut -d':' -f2- | grep Float {-# SPECIALISE instance Num (Complex Float) #-} {-# SPECIALISE instance Fractional (Complex Float) #-} {-# SPECIALISE instance Floating (Complex Float) #-} {-# SPECIALISE instance Floating (Complex Double) #-} {-# SPECIALIZE properFraction :: Float -> (Int, Float) #-} {-# SPECIALIZE round :: Float -> Int #-} {-# SPECIALIZE ceiling :: Float -> Int #-} {-# SPECIALIZE floor :: Float -> Int #-} {-# SPECIALIZE properFraction :: Float -> (Integer, Float) #-} {-# SPECIALIZE truncate :: Float -> Integer #-} {-# SPECIALIZE round :: Float -> Integer #-} {-# SPECIALIZE ceiling :: Float -> Integer #-} {-# SPECIALIZE floor :: Float -> Integer #-} {-# SPECIALIZE showEFloat :: {-# SPECIALIZE showFFloat :: {-# SPECIALIZE showGFloat :: moussor:libraries/ grep "SPECIALI[SZ]E" `find . | grep 'hs$'` | cut -d':' -f2- | grep Double {-# SPECIALISE conjugate :: Complex Double -> Complex Double #-} {-# SPECIALISE mkPolar :: Double -> Double -> Complex Double #-} {-# SPECIALISE cis :: Double -> Complex Double #-} {-# SPECIALISE polar :: Complex Double -> (Double,Double) #-} {-# SPECIALISE magnitude :: Complex Double -> Double #-} {-# SPECIALISE phase :: Complex Double -> Double #-} {-# SPECIALISE instance Num (Complex Double) #-} {-# SPECIALISE instance Fractional (Complex Double) #-} {-# SPECIALISE instance Floating (Complex Double) #-} {-# SPECIALIZE properFraction :: Double -> (Int, Double) #-} {-# SPECIALIZE round :: Double -> Int #-} {-# SPECIALIZE ceiling :: Double -> Int #-} {-# SPECIALIZE floor :: Double -> Int #-} {-# SPECIALIZE properFraction :: Double -> (Integer, Double) #-} {-# SPECIALIZE truncate :: Double -> Integer #-} {-# SPECIALIZE round :: Double -> Integer #-} {-# SPECIALIZE ceiling :: Double -> Integer #-} {-# SPECIALIZE floor :: Double -> Integer #-} {-# SPECIALISE fromRat :: Rational -> Double, -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

FFI
by Allan Bruno 07 Aug '02

07 Aug '02

Hi, my name is Allan, i'm from Brazil, and I have a doubt. I have one program in haskell that function in C passes two arrays for one which adds the two and returns one 3º. How I make to import this function and to use it in my program? Which is the mapping of the arrays of haskell for the C? Thanks !

1 0

>2gb memory usage ==> segementation fault?
by Hal Daume III 06 Aug '02

06 Aug '02

Hi all, me again :) I keep trying to get my program to run through with all my data, but once it hits around 2 or 2 1/2 gb of memory allocated (according to top), it seg faults and emits a rather sizeable (2.5 gb) core dump. Rather than sending around my 5k line program, here's a simple one which exhibits the same problem: -- UseMemory.hs module Main where import Control.Monad import Control.Monad.ST import Data.Array.ST import System mkArrays :: Int -> Int -> ST s (STArray s Int (STArray s Int Int)) mkArrays src dst = newArray_ (0,src) >>= \arr -> mapM_ (\i -> newArray (0,dst) i >>= writeArray arr i) [0..src] >> return arr sumArrays :: STArray s Int (STArray s Int Int) -> ST s Int sumArrays arr = foldM (\s i -> readArray arr i >>= \arr' -> foldM (\s j -> readArray arr' j >>= return . (s+)) s [0..snd (bounds arr')]) 0 [0..snd (bounds arr)] main = do [ssize,dsize] <- getArgs print $ runST (mkArrays (read ssize) (read dsize) >>= sumArrays) I compile with -O2 -fvia-c, and then run: 9:52am enescu:TryMPI/ ./UseMemory 1 20000 +RTS -K128m 20001 9:53am enescu:TryMPI/ ./UseMemory 1 2000000 +RTS -K128m -A64m 2000001 9:54am enescu:TryMPI/ ./UseMemory 100 2000000 +RTS -K128m -A64m Segmentation fault 1858.28u 51.66s 35:26.02 89.8% (The -A is because if you don't increase the GC size, the program executes ridiculously slowly.) Unfortunately, this behavior is entirely predictable; no matter what arguments you use, once it gets to about 2.2 gb of memory usage it dies. (This is running on a solaris 2.8 machine with 8gb main memory, about 5 or 6gb free.) Could someone explain to me what's going on here? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Lazy bind...
by MR K P SCHUPKE 05 Aug '02

05 Aug '02

Is there any way to do a lazy bind operation, something like a <- $ getLine return (Constructor $ a) this works for computations in the IO monad :- a <- unsafeInterleaveIO getLine return (Constructor $ a) but I need to do this for a general monad M. Keean Schupke Department of Electrical & Electronic Engineering, Imperial College London.

5 8

RE: infixed implicit parameters
by Simon Peyton-Jones 02 Aug '02

02 Aug '02

Reasonable suggestion, and not hard to implement. Definitions are more troublesome. Currently implicit parameter bindings must be of the form ?x = e I.e. no pattern-matching, function defintions etc. Changing this would be quite a bit more work. One could imagine a) status quo b) allow infix application, but keep binding syntactically restricted c) allow arbitrary binding forms (pattern matching etc) I think (b) is defensible; I don't think (c) is worth the work. But I would prefer to do (b) in sync with Hugs. Let's see what they think. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 23 July 2002 18:38 | To: GHC Users Mailing List | Subject: infixed implicit parameters | | | in the cannonical sort with implicit params, i we write | something like: | | mySort :: (?cmp :: a -> a -> Ordering) => [a] -> [a] | mySort [] = [] | mySort (x:xs) = insert x (mySort xs) | where insert x [] = [x] | insert x (y:ys) | | ?cmp x y == GT = y : insert x ys | | otherwise = x : y : ys | | but we cannot write for the second-to-last line: | | x `?cmp` y | | or | | x ?`cmp` y | | any chance this will be changed (my preference would be for | the first one. | | - hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

"ignoring polymorphic case..."
by Hal Daume III 31 Jul '02

31 Jul '02

I'm getting the WARNING: ignoring polymorphic case in interpreted mode. Possibly due to strict polymorphic/functional constructor args. Your program may leak space unexpectedly. warning in GHCi (5.04). I'm used to getting this when I have a datatype with strict arguments, but the only data type I have in this module (and it doesn't import any of my own modules) is: newtype GArray s key elt = GA ((STRef s (Int, STArray s Int (key, elt)))) should I be worried? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

RE: "ignoring polymorphic case..."
by Simon Marlow 31 Jul '02

31 Jul '02

> WARNING: ignoring polymorphic case in interpreted mode. > Possibly due to strict polymorphic/functional constructor args. > Your program may leak space unexpectedly. > > warning in GHCi (5.04). I'm used to getting this when I have > a datatype > with strict arguments, but the only data type I have in this > module (and > it doesn't import any of my own modules) is: > > newtype GArray s key elt = GA ((STRef s (Int, STArray s Int > (key, elt)))) > > should I be worried? These might also crop up as a result of using seq. Don't be worried unless you are using seq on purpose to avoid space leaks or to force (unsafe) I/O to happen. The warning essentially means that the seq is being ignored by GHCi because of an implementation wibble. Cheers, Simon

1 0

RE: STUArrays for Pairs
by Simon Marlow 31 Jul '02

31 Jul '02

> > it seems to me that if you have > > > > instance MArray (STUArray s) a (ST s) > > > > and > > > > instance MArray (STUArray s) b (ST s) > > > > you should be able to have > > > > instance MArray (STUArray s) (a,b) (ST s) > > > > by simply keeping two arrays with identical bounds, one > holding as and one > > holding bs, and then when you lookup, you lookup in each > individually and > > pair. > > > > i'd like to write such an instance, but have no idea where > to start...any > > pointers? > > It's a little bit more difficult, but possible. Have a look > at I'll confess I haven't looked into your stuff in any great detail, but I'm wondering whether Hal's idea can be achieved without any extra machinery. Here's my best shot; it's not entirely satisfactory because there's an extra dummy type parameter to the STUPairArray type constructor, and you need -fallow-undecidable-instances, but it seems to do the job: module PairArray where import Data.Array.Base import Control.Monad.ST data STUPairArray a b s i t = STUPairArray (STUArray s i a) (STUArray s i b) instance HasBounds (STUPairArray a b s) where bounds (STUPairArray left right) = bounds left instance (MArray (STUArray s) a m, MArray (STUArray s) b m) => MArray (STUPairArray a b s) (a,b) m where newArray (l,u) (a,b) = do lft <- newArray (l,u) a rgt <- newArray (l,u) b return (STUPairArray lft rgt) unsafeRead (STUPairArray lft rgt) i = do a <- unsafeRead lft i b <- unsafeRead rgt i return (a,b) unsafeWrite (STUPairArray lft rgt) i (a,b) = do unsafeWrite lft i a unsafeWrite rgt i b Cheers, Simon

2 1

RE: question about RealWorld and realWorld#
by Simon Marlow 31 Jul '02

31 Jul '02

> Am I right in saying that the type constructor > RealWorld is special to the compiler in that it is not defined in > any Haskell code but wired in? Yes, it is a primitive type, albeit a very special one. RealWorld is only used to instantiate the type parameter of the State# type constructor (another primitive type) in the IO monad and in runST. > Am I also correct is saying that the identifier realWorld# is > similar in > that it isn't defined in any Haskell code, but is primitive > to the compiler? Yes. > I would have expected to find something like: > > realWorld# :: State# s > realWorld# = undefined There isn't really a way to define the value of realWorld# in Haskell. Think of realWorld# as a constant of type State# RealWorld. > My instinctive feeling is that GHC treats State# objects > specially, so that > they only live at compile time but are not present at > runtime. This is mentioned > in the "Lazy functional state threads" paper: > > "By the time the program reaches the code generator, the > role of the state > values is over, and the code generator arranges to > generate no code at all > to move around values of type State#" (page 13 in my > version of the paper). They are "almost invisible" at runtime. For example, there must still be a difference between a function of type 'State# s -> a' and a value of type 'a', although the argument doesn't have a value and doesn't use any registers. HTH, Simon

1 0

FiniteMap.keysFM
by Christian Maeder 31 Jul '02

31 Jul '02

Designers of FiniteMap and Set (it's me again), I wish "keysFM" would yield "Set key" rather than "[key]"! Could such an implementation take constant time (by simply ignoring "elts")? (Converting a list to a set and back will sort the list and thus may take more than linear time.) Cheers Christian

2 2