Re: [Haskell-cafe] Sample rate inference
On Thu, 11 Nov 2004 10:49:13 +0100 (MEZ) Henning Thielemann [EMAIL PROTECTED] wrote: The computation sample rate should be propagated through the network as follows: If in a component of equal sample rate some processors have the same fixed sample rate, all uncertain processors must adapt that. If some processors have different fixed sample rates this is an error. If no processor has a fixed sample rate, the user must provide one manually. To me this looks very similar to type inference. Is there some mechanism in Haskell which supports this programming structure? This may not what you are looking for, but I would simply use Reader Monad or like. newtype Rate = Rate Int type Processor = Stream - Reader Rate Stream processor1 s = do rate - ask; ... processors = processor1 = processor2 = .. process = runReader (processors input) (Rate 44100) P.S. Sorry for sending the same mail. I didn't notice you set Reply to. -- Koji Nakahara ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Arrows (Re: [Haskell-cafe] Sample rate inference)
On Fri, 12 Nov 2004 01:10:06 +0900
Koji Nakahara [EMAIL PROTECTED] wrote:
On Thu, 11 Nov 2004 10:49:13 +0100 (MEZ)
Henning Thielemann [EMAIL PROTECTED] wrote:
The computation sample rate should be propagated through the network as
follows:
If in a component of equal sample rate some processors have the same
fixed sample rate, all uncertain processors must adapt that.
If some processors have different fixed sample rates this is an error.
If no processor has a fixed sample rate, the user must provide one
manually.
To me this looks very similar to type inference. Is there some mechanism
in Haskell which supports this programming structure?
This may not what you are looking for,
but I would simply use Reader Monad or like.
I fall on Arrows and come up with the following.
I'm not sure this is a proper usage of Arrows, though.
I'd appreciate any advices.
--
{-# OPTIONS -fglasgow-exts #-}
import Control.Arrow
import Data.List (intersect)
data Rates = Rates [Int] | Any deriving Show
data Processor b c = P Rates (Rates - (b, Stream) - (c, Stream))
-- test Stream
type Stream = String
intersectRates Any (Rates xs) = Rates xs
intersectRates (Rates xs) (Rates ys) = Rates $ intersect xs ys
intersectRates x y = intersectRates y x
instance Arrow Processor where
arr f = P Any (\r (x, s) - (f x, s))
(P r0 f0) (P r1 f1)
= P (intersectRates r0 r1) (\r - (f1 r) . (f0 r))
first (P r f) = P r (\r ((x, y), s) - let (z, s') = f r (x, s)
in ((z, y), s'))
runProcessor (P r f) a s = f r (a, s)
-- test processors
processor1 = P (Rates [44100, 48000]) (\r (x, s) - ((), s ++ show r))
processor2 = P Any (\r (x, s) - ((),(s ++ show r)))
processor3 = P (Rates [48000]) (\r (x, s) - ((), (s ++ show r)))
process = processor1 processor2 processor3
--
Koji Nakahara
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Making MVar and Chan Instances of Typeable
On Fri, 5 Nov 2004 14:43:55 +0100 Benjamin Franksen [EMAIL PROTECTED] wrote: snip the instances by hand. My first attempt was: instance Typeable a = Typeable (MVar a) where typeOf x = mkAppTy (mkTyCon Control.Concurrent.MVar.MVar) [typeOf (undefined::a)] but unfortunately this doesn't work. Ghc complains about Ambiguous type variable `a1' in the top-level constraint: `Typeable a1' arising from use of `typeOf' at Helpers.hs:8 The reason is apparently that inside the definition of typeOf the type variable 'a' is not unified with the 'a' from the instance header. I could write You can write: instance Typeable a = Typeable (MVar a) where typeOf (x :: MVar a) = mkAppTy (mkTyCon Control.Concurrent.MVar.MVar) [typeOf (undefined::a)] Hope it helps, Koji Nakahara ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] executable scripts?
On Fri, 22 Oct 2004 16:05:29 -0700 John Velman [EMAIL PROTECTED] wrote: One of the nice things about perl (for example) is that you can put together a script with #!/usr/local/perl (in bash for example) as the first line of a file and run it immediately. I've used perl a lot this way with simple 'throw away' scripts to do special filtering on a file, or some other processing that I want to do one or a few times. occasionally, a script like this will have a more permanant value to me, and I keep it around. Is there some way to do something similar in with Haskell? I've tried the most obvious (to me) test with Hugs and it doesn't work. #!/usr/local/bin/runhugs will do the trick. See hugs(1). Haskell does really good job for me where perl had been used! -- Koji Nakahara ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] existential type problem
On Fri, 15 Oct 2004 19:55:02 -0400 Andrew Pimlott [EMAIL PROTECTED] wrote: data Foo = forall t. (MonadTrans t) = Foo ((Monad m, Monad (t m)) = t m a - m a)-- run ((Monad m, Monad (t m)) = t m Int) -- op prog :: Foo - IO Int prog (Foo run op) = run $ do lift $ putStrLn Running prog op ghci gives the error Could not deduce (Monad (t IO)) from the context (MonadTrans t) arising from use of `op' at try.hs:22 Your prog leaks m (= IO) out of Foo. I guess you mean: data Foo m = forall t. (MonadTrans t, Monad (t m)) = Foo (forall a. t m a - m a) (t m Int) prog :: Foo IO - IO Int prog (Foo run op) = run $ do lift $ putStrLn Running prog op test = prog (Foo (flip evalStateT 0) get) -- Koji Nakahara ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell]
On Tue, 2 Mar 2004 09:52:46 + Alastair Reid [EMAIL PROTECTED] wrote: -- snip Maybe we can have both sets of operations? This could be done either using two separate Array types or by having two variants of a few of the array ops. Nice. I personally have not needed that check yet, but of course it's just me. I read somewhere that GHC doesn't check duplicate indices because it makes array construction too slow. However GHC could leave it to the users choice by supplying a compiler flag. I'm very happy because one of the most experienced Haskell programmer considered my argument as convincing. Thank you. -- Koji Nakahara ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Incremental Array update (Re: performance tuning Data.FiniteMap)
Hi, Reading the recent discussions abount Array and FiniteMap, I want to know what people think about the current specification of the Array update. The Array implementaton of GHC effectively has this property (like FiniteMap): (arr // cs1) // cs2 == arr // (cs1 ++ cs2) -- allow duplicate indices Because (//) copies a whole array and slow, instead of the successive updates, I usually accumulate those changes to a list as many as I can in advance, and then give it to (//). As far as GHC is concerned, all we have to do is to concatenate the list of changes by (++) thanks to the propety. It generally results in a huge performance inprovement. However, Haskell Report reads (16.2): (As with the array function, the indices in the association list must be unique for the updated elements to be defined.) So, we must somehow (as oleg's add_uniq[1]) remove the preceding elements having the same index from the list to make the program comply Haskell 98 and support Hugs since Hugs does implement that check. The preconditioning (and also the check performed by the runtime system) causes no small amount of performance hit. I think it would be better if the above property of incremental updates of Array is guaranteed sometime hopefully in Haskell 2. Note: 0) Array give us O(1) read. 1) FiniteMap has the same property. 2) Array is more convenient than monadic arrays, e.g. STArray. 3) Array is faster than ST(U)Array in my experience, if the size of the array is no more than about 100 (when the updates can be combined). 4) The runtime optimization which converts (arr // cs1) // cs2 to arr // (cs1 ++ cs2) might be possible? [1] http://www.haskell.org//pipermail/haskell/2004-February/013724.html --- Koji Nakahara ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] What are possible causes of C stack overflow in Hugs?
On Wed, 04 Feb 2004 23:00:50 +
Graham Klyne [EMAIL PROTECTED] wrote:
I'm getting a C stack overflow error from Hugs when processing a
moderately large dataset, but not doing anything that looks unreasonably
complex or involved.
snip
I think the function graphLabels1 is set to call itself recursively to a
depth of a little over 1000. Can this kind of recursion blow the Hugs stack?
foldl f x xs generally requires #xs (the number of elements of xs) stacks to be
evaluated.
Note that ls(the second argument of graphLabels1) is not evaluated until
graphLabels1 [] ls = ls
.
foldl (flip addSetElem) ls (arcLabels t)
ls is also defined by a foldl and its ls is also ...
So, let gs = [g_1, g_2, ..., g_N],
you need at least \sum_{n = 1}^N #g_n stacks. Is'n it large?
The simplest and safest solution is to change foldl to foldl', but it produces
the unnecessary evaluation of `elem`s in addSetElem's.
I think that
import DeepSeq
{- or
f $!! x = force x `seq` f x
where force [] = ()
force (x:xs) = x `seq` force xs
-}
...
graphLabels1 (t:gs) ls = graphLabels1 gs $!! foldl (flip addSetElem) ls (arcLabels t
is better in your case.
Sorry for my poor English and hope it helps,
Koji Nakahara
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] What are possible causes of C stack overflow in Hugs?
The simplest and safest solution is to change foldl to foldl', but it produces the unnecessary evaluation of `elem`s in addSetElem's. Wrong. Please ignore it. $!! is better in a sense that it reduces the stack usage further than foldl' (foldl''s second argument needs stacks to be evaluated). -- Koji Nakahara ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] partition in Data.List bug
Hi,
I've encountered a bug of partition in Data.List shipped with
ghc-6.2 and hugs(Nov 2002)
It cannot work with an infinite list.
Example:
partition (==0) (cycle [0,1])
does not return and so
not conform to the specification in the Haskell 98 and the library document.
I found some discussion on this bug in the haskell mailing-list archive,
e.g. http://www.mail-archive.com/[EMAIL PROTECTED]/msg07789.html
Is there some good reason not to change this behaviour?
(And if it is, I think that the library document should be fixed.)
Patch:
--- List.hs.origThu Feb 5 04:15:59 2004
+++ List.hs Thu Feb 5 04:16:31 2004
@@ -240,8 +240,8 @@
{-# INLINE partition #-}
partition p xs = foldr (select p) ([],[]) xs
-select p x (ts,fs) | p x = (x:ts,fs)
- | otherwise = (ts, x:fs)
+select p x ~(ts,fs) | p x = (x:ts,fs)
+| otherwise = (ts, x:fs)
-- @mapAccumL@ behaves like a combination
-- of @map@ and @foldl@;
---
Koji Nakahara
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Generalized list-comprehension
Hi, Another solution: f m n = concat $ take m $ tail xs where xs = [[]]:map (\x - concatMap (\y - map (y:) x) [1..n]) xs f 3 4 gives your f 4. Hope it helps, Koji Nakahara On Sat, 31 Jan 2004 07:35:38 -0800 (PST) Ron de Bruijn [EMAIL PROTECTED] wrote: Hi there, I have written this little function: f :: (Num a, Enum a) = a - [[a]] f n = [[a]|a-fu n] ++ [a:[b]|a-fu n,b-fu n] ++ [a:b:[c]|a-fu n,b-fu n,c-fu n] fu n = [1..n] This is an example of the function in action: *Mod f 4 [[1],[2],[3],[4],[1,1],[1,2],[1,3],[1,4],[2,1],[2,2],[2,3],[2,4],[3,1],[3,2],[3, 3],[3,4],[4,1],[4,2],[4,3],[4,4],[1,1,1],[1,1,2],[1,1,3],[1,1,4],[1,2,1],[1,2,2] ,[1,2,3],[1,2,4],[1,3,1],[1,3,2],[1,3,3],[1,3,4],[1,4,1],[1,4,2],[1,4,3],[1,4,4] ,[2,1,1],[2,1,2],[2,1,3],[2,1,4],[2,2,1],[2,2,2],[2,2,3],[2,2,4],[2,3,1],[2,3,2] ,[2,3,3],[2,3,4],[2,4,1],[2,4,2],[2,4,3],[2,4,4],[3,1,1],[3,1,2],[3,1,3],[3,1,4] ,[3,2,1],[3,2,2],[3,2,3],[3,2,4],[3,3,1],[3,3,2],[3,3,3],[3,3,4],[3,4,1],[3,4,2] ,[3,4,3],[3,4,4],[4,1,1],[4,1,2],[4,1,3],[4,1,4],[4,2,1],[4,2,2],[4,2,3],[4,2,4] ,[4,3,1],[4,3,2],[4,3,3],[4,3,4],[4,4,1],[4,4,2],[4,4,3],[4,4,4]] *Mod snip ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalized list-comprehension
I need to map(\x-otherFunction x) [1..], but this next-function is almost identical to what the built-in listcomprehension does. I just don't like my solution. Sorry, I didn't read this. You may prefer something like this to map (\x - otherFunction x), though mechanical translation: xs = [[]]:[[ y:z | y - [1..n], z - x] | x - xs] Hope it helps, Koji Nakahara On Sun, 1 Feb 2004 15:22:01 +0900 Koji Nakahara [EMAIL PROTECTED] wrote: Hi, Another solution: f m n = concat $ take m $ tail xs where xs = [[]]:map (\x - concatMap (\y - map (y:) x) [1..n]) xs f 3 4 gives your f 4. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Stack usage with a state monad
Hi, I think the problem is in the State Monad itself; State Monad is lazy to compute its state. I am not a haskell expert, and there may be better ideas. But anyhow, when I use these = and instead of = and , your example runs fine. I hope it becomes some help. m = k = State $ \s - let (a, s') = runState m s in s `seq` runState (k a) s' -- force evaluation of the state m k = m = \_ - k -- Koji Nakahara ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Common subexpressions are not optimized to single one?
My original mail might be misleading, but I didn't mean that I want to
rely on the optimization to make the program work.
I just thought If I could expect such an optimization to be performed,
I would not need to rewrite everytime
func (g x) (g x) -- g x = unsafeperformIO $ do {...}
to
let h = g x in func h h
in order to make the program run faster.
But ,in the first place, is it meaningful to write let h = g x in func h h
in order to avoid re-evaluation of g x, on the assumption that h is CAF?
Thanks.
--
Koji Nakahara
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Common subexpressions are not optimized to single one?
Hi,
I'm wondering about the optimization of ghc. I thought that since
functions are pure in haskell, compiler can/do factorize common
subexpressions when it optimizes a code. But the result of the following
experiment looks negative; g 10 100 is caluculated twice.
Am I missing something? If not,
What prevents ghc from performing that optimization?
Should I always factorize common subexpressions manually(using let or where)?
---
$ cat op.hs
module Main
where
import System.IO.Unsafe
foreign import ccall count io_count:: IO Int
f :: Int - IO Int
f x = do {y - io_count; return $ x + y}
g :: Int - Int - Int
g x y = unsafePerformIO $ do {z - f x; return $ z + y}
main = do print (g 10 100, g 10 100)
$
$ cat ffi_test_c.c
static int counter = 0;
int count() {return counter++;}
$
$ gcc -c ffi_test_c.c;ghc -O2 -ffi op.hs;ghc -o op_test op.hs ffi_test_c.o
$ ./op_test
(110,111)
---
I want to use some C functions from haskell each of which is not pure but
the result of their sequential combination is pure. I'm planning to write
some functions like g above(but more complex and actually pure) and
considering the optimization of the code using them.
Thanks in advance.
Koji Nakahara
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Help: Stack-overflow and tail-recursive functions
On Fri, 20 Jun 2003 07:54:50 -0700 Hal Daume [EMAIL PROTECTED] wrote: mine didn't either, until I increased the 200 to around 1500...it's probably OS/memory specific. Only 600 causes the stack overflow in my environment(FreeBSD, 640MB). Interestingly, on GHCi, the program shows the elements which are constructed from the first row of the matrix, rests awhile and then stack overflows (n = 600) or continues fine (n = 500). With the improved definition of rmat I wrote in my last mail (Subject: listArray and stack overflow (Re: Help: Stack-overflow and tail-recursive functions)) it runs without both that rest and stack overflow (at least n = 2000). ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
listArray and stack overflow (Re: Help: Stack-overflow and tail-recursive functions)
I did some experiments and now suspect that the culprit is the infinite list. When I replace rmat with rmat n = listArray ((1,1),(n,n)) [1..] -- no longer random , print (m ! (300, 300)) where m = rmat 800 fails again. However, if I use a finite list as the second argument of listArray: rmat n = listArray ((1,1),(n,n)) [1..(n*n)] , then the program runs without problems. This definition works as well as oleg's. rmat n =listArray ((1,1),(n,n)) $!! (take (n*n) $ map ct (randoms (mkStdGen 1) ::[Bool]) ) where ct True = Unknown ct False = Dead I think: If the list is infinite, listArray doesn't return an array as data. Each time an element of the array is used, the list is evaluated. This lazy evaluation require some stack(and the access time cannot be constant?). Is it correct? Thank you. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
